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1.  INTRODUCTION 


This  Programmer’s  Manual  is  one  of  the  manuals  documenting  the  Automated  STRuctural  Opti¬ 
mization  System  (ASTROS).  The  other  three  are  the  Theoretical  Manual,  the  User's  Manual  and  the 
Applications  Manual.  The  Theoretical  and  Applications  Manual  indicate  the  range  of  capabilities  of  the 
ASTROS  system  while  the  User’s  Manual  provides  a  complete  description  of  the  user  interface  to  the 
system.  The  Programmer’s  Manual  gives  the  detailed  description  of  ASTROS  software.  It  describes  the 
system  in  terms  of  its  software  components,  documents  the  procedure  for  installing  ASTROS  on  different 
host  machines  and  provides  detailed  documentation  of  the  application  and  utility  modules  that  comprise 
the  procedure.  In  addition,  the  data  structures  of  the  database  entities  are  presented  in  detail.  This 
manual  is  intended  to  provide  the  system  administrator  with  a  guide  to  the  existing  software  and  the 
researcher  with  sufficient  information  to  add  application  modules  or  otherwise  manipulate  the  data 
generated  by  the  ASTROS  system.  Using  standard  ASTROS  features  does  not  require  a  familiarity  with 
the  information  contained  in  this  manual  except,  perhaps,  for  the  entity  documentation,  which  is  useful 
when  additional  database  entities  are  to  be  viewed. 

This  document,  while  useful  to  the  advanced  engineering  user,  is  directed  toward  the  system 
administrator  and/or  code  developer.  This  is  the  individual  referred  to  by  the  term  user  unless  otherwise 
indicated.  The  Programmer’s  Manual  is  structured  in  this  way  because  all  the  information  needed  by  the 
engineering  user  is  contained  as  a  subset  of  that  needed  by  the  system  administrator.  As  a  consequence, 
however,  the  manual  is  not  as  simple  for  the  analyst  as  might  be  desired.  It  is  anticipated  that  the 
advanced  application  user  will  need  to  sift  through  the  module  documentation  and  entity  documentation 
to  extract  the  information  needed  to  modify  the  ASTROS  execution  path  or  to  insert  additional  modules 
for  performing  alternative  computations,  printing  additional  results,  writing  data  in  alternative  formats 
or  other  advanced  features  that  may  be  performed. 

As  an  introduction  to  the  ASTROS  system,  Section  2  contains  a  description  of  the  software 
structure  of  ASTROS,  both  to  provide  a  resource  for  the  system  administrator  and  to  be  a  road  map  for 
the  application  user  in  identifying  specific  modules  relevant  to  the  task  of  interest.  Section  2  attempts  to 
introduce  the  user  to  the  totality  of  ASTROS  source  code  and  their  interrelationships  so  that  subsequent 
reading  will  be  more  readily  interpretable:  in  essence,  Section  2  provides  a  nomenclature  section  enabling 
the  reader  to  identify  (with  the  inevitable  exceptions)  the  major  unit  (module)  or  functional  library  to 
which  a  particular  program  belongs.  This  section  provides  a  framework  for  subsequent  sections  in  the 
Programmer’s  Manual. 
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Section  3  is  devotee,  to  the  instsTation  of  the  ASTROS  system  on  alternative  host  machines.  Thc|fill§ 
steps  involved  in  installing  the  vsten?  'trt  given,  followed  by  detailed  documentation  of  all  the  machine 
and  installation  dependent  code.  Sufficient  decail  is  given  to  allow  someone  familiar  with  the  target  host 
system  to  write  a  set  of  machine-dependent  co  'e  for  that  machine  or  site.  This  documentation  is  followed 
by  the  description  of  the  System  Generation  Process  (SYSGEN)  and  its  inputs.  These  inputs,  along  with 
the  SYSGEN  program,  define  the  system  database  *hich,  in  turn,  defines  system  data  to  the  ASTROS 
executive.  It  is  these  inputs  which  the  reeiarciw  may  wish  to  modify  to  define  a  new  module,  define  a 
new  set  of  inputs  or  make  other  advanced  me  Jificatons  of  the  system.  A  brief  presentation  of  the  order  of 
the  operations  that  follow  preparation  of  the  machine  dependent  library  is  given  to  complete  an  installa¬ 
tion  of  the  system. 

Sections  4  through  8  contain  the  formal  doc  umentadon  of  the  ASTROS  modules.  Section  4 
documents  those  portions  of  the  code  that  are  considered  to  be  at  the  system  level.  This  means  that  the 
user  need  not  be  aware  of  their  existence  but  they  are  important  in  the  overall  system  architecture. 
Further,  they  perform  many  tasks  of  which  the  user  may  want  to  be  aware  if  any  system  modifications 
are  to  be  made.  Sections  8  through  8  document  the  utilities  that  are  associated  with  the  ASTROS 
application  modules,  matrix  operations  and  the  database.  These  sections  axe  the  most  important  from  the 
view  of  the  advanced  researcher/user  in  that  these  are  the  software  tools  from  which  additional  capabili¬ 
ties  can  be  put  together  with  reasonable  rapidity.  In  each  case,  the  executive  (MAPOL)  and  application 
interface  is  fully  defined  and  the  algorithm  of  the  utility  is  outlined. 

Section  9  contains  the  documentation  of  the  data  structures  on  the  CADDB  database  that  are 
used  by  the  ASTROS  system.  The  contents  and  structure  of  each  database  entity  are  gi  n?n  along  with  an 
indication  of  the  module  that  generates  the  data  and  which  modules  use  the  data.  For  matrix  entities,  the£| 
relevant  saecion  of  the  Theoretical  Manual  is  also  referenced  since  the  entity  contents  are  more  clearly^® 
underati  od  in  the  content  of  the  equations  that  are  highlighted  there. 

Section  10  contains  a  presentation  of  notes  for  the  ASTROS  application  programmer.  It  is  felt 
that  the  ASTROS  system  has  been  designed  with  sufficient  flexibility  that  the  additional  features  or 
minor  enhancements  are  desired.  Section  10,  therefore,  attempts  to  address  some  issues  involved  in 
writing  an  ASTROS  module.  Rules  and  guidelines  are  given  which  will  help  the  programmer  avoid 
complications  arising  from  the  interface  of  the  new  module  and  application  utilities  are  also  given. 
Particular  emphasis  is  placed  on  the  memory  management  utilities  and  the  database  utilities  since  these 
require  a  more  sophisticated  interface  than  the  simple  application  utilities. 


A  standard  documentation  format  has  been  adopted  for  the  modules  that  are  described  in  Section 
3  through  8.  Figure  i  illustrates  this  format  and  provides  a  key  for  identifying  the  data  that  are  given  for 
each  module.  While  this  format  is  brief,  enough  information  is  given  for  the  user  to  identify  the  principal 
action  of  the  module  and  the  role  it  plays  in  the  standard  ASTROS  execution.  The  utility  modules  are 
documented  to  the  extent  necessary  for  an  application  programmer  to  use  the  utility  in  any  new  code  to 
be  inserted  in  the  system. 
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2.  ASTROS  SOFTWARE  DESCRIPTSON 


ASTROS  is  a  software  system  made  up  of  two  separate  executable  programs  comprising  over 
1500  independently  addressable  code  segments  containing  approximately  300,000  lines  of  FORTRAN. 
While  this  Programmer’s  manual  is  devoted  primarily  to  the  detailed  documentation  to  the  separate 
modules  and  subroutines  of  the  ASTROS  system,  an  overview  of  that  system  is  necessary  to  understand 
how  the  individual  pieces  fit  together.  This  section  introduces  the  ASTROS  system  and  describes  the 
software  structure  of  ASTROS  in  terms  of  its  major  code  blocks.  Both  the  system  generation  program, 
SYSGEN,  and  the  main  program,  ASTROS,  are  described  and  their  interrelationships  are  illustrated. 
This  section  provides  a  resource  for  the  system  administrator  and  a  road  map  for  the  application  pro¬ 
grammer  to  identify  the  section  documenting  modules  relevant  to  the  task  of  interest.  This  section  also 
provides  a  framework  to  direct  the  subsequent  sections  in  the  Programmer’s  Manual. 

In  the  context  of  the  Programmer’s  Manual,  the  structure  of  the  ASTROS  system  refers  to  the 
interrelationships  among  the  mqjor  code  blocks.  Typically,  an  analysis  of  the  software  associated  with  an 
individual  code  segment  will  indicate  the  nature  of  the  task  being  performed  and  provide  information  on 
the  mechanisms  by  which  intramodular  communication  takes  place.  The  larger  picture,  in  which  the 
intermodular  requirements  of  a  particular  code  segment  becomes  clear,  is  more  difficult  to  grasp.  It  is 
that  picture  which  this  section  attempts  to  provide. 

The  magnitude  of  the  ASTROS  system  requires  that  the  code  segments  be  grouped  into  abstract 
collections  of  code  such  as  utility  modules  and  the  database  in  order  to  be  understood.  While  necessary, 
these  abstract  collections  can  also  obscure  the  picture  cf  the  system  since  a  great  deal  of  the  detail  is 
necessarily  lost.  Nonetheless,  since  a  discussion  of  each  individual  code  segment  is  not  possible,  a  set  of 
code  blocks  has  been  defined  for  the  purpose  of  writing  the  Programmer’s  Manual.  Naturally,  there  are 
many  ways  in  which  the  code  segments  could  be  grouped  to  aid  the  user  in  understanding  the  code 
segments  and  their  interactions.  For  the  Programmer’s  Manual,  the  code  is  grouped  in  a  hierarchical 
manner  by  function:  that  is,  code  segments  that  perform  similar  tasks  at  a  similar  level  (relative  to  the 
executive  system)  are  grouped  together.  Some  segments  of  the  code,  of  course,  do  not  fit  clearly  into  this 
so  rt  of  functional  abstraction.  Their  role  is  such  that  they  could  lie  in  more  than  one  group  or  really  don’t 
belong  to  any  group  that  has  been  defined.  These  exceptions  complicate  the  issue  but  do  not  destroy  the 
utility  of  the  functional  breakdown  of  the  code.  When  a  module  could  be  documented  with  more  than  one 
ceay  gioup,  this  fact  is  noted  in  the  appropriate  manual  sections. 
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2.1.  THE  ASTROS  SYSTEM 

The  highest  level  of  abstraction  is  illustrated  in  Figure  2,  which  presents  the  two  executable 
images  that  comprise  the  ASTROS  system,  theii  inputs,  outputs,  and  interrelationships.  Referring  to  the 
figure,  each  of  the  illustrated  components  is  briefly  described  in  the  following  sections. 

2.1.1.  SYSGEN  Components 

The  SYSGEN  program  is  a  stand-alone  executable  program  that  is  used  to  define  ASTROS 
system  parameters.  The  use  of  an  executable  program  that  is  directed  by  a  set  of  inputs  was  adopted  to 
provide  a  simple  mechanism  tc  expand  the  capabilities  of  the  ASTROS  procedure.  The  inputs,  outputs, 
and  use  of  this  very  important  feature  of  the  ASTROS  architecture  are  fully  documented  in  Section  3.2. 
The  SYSGEN  program  consists  of  five  items  indicated  by  the  numbered  boxes  in  Figure  2.  Each  of  these 
is  briefly  discussed  below: 

1.  The  SYSGEN  INPUTS  consist  of  a  set  of  files  that  define  certain  system  level  data  that  is  written 
by  SYSGEN  to  the  system  database,  SYSDB. 

2.  SYSGEN  is  an  executable  program  that  reads  the  SYSGEN  INPUTS  and  creates  a  set  of 
database  entities  on  SYSDB  that  provide  data  to  the  ASTROS  executive  and  high  level 
engineering  modules. 

3.  The  SYSTEM  DATABASE,  SYSDB,  consists  of  an  index  file,  SYSDBIX,  and  (typically)  a  single 
data  file,  SYSDB01.  The  SYSGEN  program  creates  and  loads  database  entities  onto  the  system 
database  which  defines: 

a.  The  set  of  modules  which  can  be  addressed  through  the  MAPOL  language 

b.  Tho  set  of  relational  schemata  for  all  relations  declared  in  the  MAPOL  sequence 

c.  The  set  of  input  Bulk  Data  entries 

d.  The  error  message  texts  for  most  run  time  error  messages 

e.  The  standard  MAPOL  sequence  to  direct  the  execution  of  the  ASTROS 

4.  xqdriv  is  a  FORTRAN  subroutine  written  by  SYSGEN  that  must  be  compiled  and  linked  into 
the  ASTROS  executable  during  the  generation  of  the  ASTROS  executable  image.  It  is  the 
XQDRIV  subroutine  that  forms  the  FORTRAN  link  between  the  MAPOL  language  and  the 
application/utility  modules. 

5.  The  SYSGEN  OUTPUT  FILE  is  a  listing  generated  by  SYSGEN  that  echoes  all  the  data  stored 
on  the  system  database.  As  such,  it  provides  a  resource  for  the  application  user  and  the  system 
administrator  documenting  the  current  ASTROS  system.  Since  this  file  represents  what  is,  by 
definition,  the  ASTROS  program,  any  problems  that  arise  or  questrons  m  the  documentation 
should  be  checked  against  the  data  in  this  file.  If  any  discrepancies  exist,  either  the  documen¬ 
tation  is  in  error  or  the  SYSGEN  inputs  are  in  error.  In  any  case,  the  ASTROS  program  is  directed 
by  the  SYSGEN  data. 
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Figure  2.  ASTROS  System  Overview 
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2.1.2.  ASTROS  Components 


As  illustrated  in  Figure  2,  the  XQDRIV  subroutine  and  SYSDB  are  also  part  of  the  ASTROS 
program.  The  XQDRIV  subroutine  is  needed  to  generate  the  executable  image  and  the  SYSDB  files  MUST 
be  available  on  a  read-only  basis  by  the  ASTROS  program  whenever  an  ASTROS  job  is  run.  The  ASTROS 
program  is  comprised  of  the  following: 

1.  xqdriv  is  a  FORTRAN  subroutine  written  by  SYSGEN  that  must  be  compiled  and  linked  into 
the  ASTROS  executable  during  the  generation  of  the  ASTROS  executable  image.  It  is  the 
XQDRIV  subroutine  that  forms  the  FORTRAN  link  between  the  MAPOL  language  and  the 
application/utility  modules. 

2.  The  SYSTEM  DATABASE,  SYSDB,  contains  database  entities  which  define  sets  of  data 
establishing  the  extent  of  some  of  the  capabihties  of  the  ASTROS  program.  ASTROS  requires 
these  files  on  a  read-only  basis  for  every  execution  of  the  system. 

3.  The  ASTROS  program  is  the  main  executable  image  associated  with  the  ASTROS  procedure.  It 
is  comprised  of  all  the  executive,  database,  utility,  and  engineering  application  modules  that  are 
needed  to  perform  the  automated  multidisciplinary  optimization  tasks. 

4.  The  INPUT  STREAM  is  the  user’s  input  file  containing  the  directives  to  execute  the  ASTROS 
program.  The  User’s  Manual  is  devoted  to  its  documentation. 

5.  The  OUTPUT  FILE  contains  the  data  written  to  the  user’s  output  file  containing  those  results 
of  the  ASTROS  execution  that  were  requested  to  be  printed  or  that  are  printed  by  default. 

6.  The  RUN-TIME  DATABASE  consists  of  one  index  file  and  one  or  more  data  files  (called, 
respectively,  RUNDBIX,  and  RUNDB01,  02,  etc.,  in  Figure  2)  that  contain  the  database 
generated  at  run  time  by  ASTROS.  Assuming  an  execution  based  on  the  standard  MAPOL 
sequence,  the  run-time  database  will  contain  some  or  all  of  the  entities  that  are  documented  in 
Section  9  of  this  manual.  The  application  user  can  direct  whether  this  database  is  to  be  saved 
or  deleted  on  termination  of  the  execution.  The  Interactive  CADDB  Environment  (ICE) 
(AFWAL-TR-88-3060,  August  1988)  can  be  used  to  view  these  data,  prepare  reports  or  port  the 
data  into  other  applications. 
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2.2.  MAJOR  FUNCTIONAL  CODE  BLOCKS 


Figure  3  presents  a  grouping  of  source  cede  blocks  within  the  ASTROS  system.  This  grouping  is 
functional  in  that  code  related  to  the  performance  of  one  task  or  a  series  of  tasks  at  the  same  level 
relative  to  the  executive  system  are  grouped  together.  According  to  this  breakdown,  there  are  seven  major 
blocks  of  code  within  ASTROS  executable  programs.  The  SYSGEN  program  has  no  executive  system  and 
is  directed  by  a  simple  FORTRAN  driver  called  SYSGEN.  The  ASTROS  system,  on  the  other  hand,  has  a 
highly  developed  executive  system  that  comprises  this  major  ASTROS  code  block.  Also  shown  are  the  five 
groups  of  routines  which  are  used  by  the  SYSGEN  and  ASTROS  programs. 

The  naming  conventions  used  within  each  code  block  are  worthy  of  some  discussion  since  they  are 
useful  in  identifying  an  unknown  routine  in  a  piece  of  ASTROS  software.  Whenever  possible,  a  set  of 
consistent,  meaningful  mnemonics  was  adopted  to  identify  groups  of  code  that  belong  together,  either 
functionally  or  logically.  Where  such  conventions  have  been  adopted,  they  are  indicated  in  the  discussion 
of  the  code  block.  One  complication  to  such  conventions  is  the  use  of  existing  source  code  as  a  resource  for 
the  ASTROS  program.  When  major  code  units  were  used  from  existing  software,  the  convention  was  not 
typically  enforced.  As  a  result,  there  are  exceptions  to  the  nomenclatures  adopted  in  some  of  the  source 
code  blocks  presented  in  this  section. 

Each  of  the  source  code  blocks  is  now  briefly  discussed  by  reference  to  the  name  assigned  to  it  in 
Figure  3  and  its  related  Programmer’s  Manual  section  is  indicated. 

1.  SYSGEN  is  a  very  small  code  block  containing  the  SYSGEN  driver  (SYSGEN),  a  set  of  four 
output  routines  (xxxoor)  so  print  the  SYSGEN  output  file  and  five  routine  (TIMxxx)  that 
compute  the  timing  constants  for  the  large  matrix  utilities.  The  SYSGEN  program  has  a  single 
execution  path  which  is  documented  in  Section  3.2. 

2.  The  ASTROS  executive  is  the  code  block  containing  the  ASTROS  main  driver  program,  ASTROS, 
and  the  ASTROS  executive  system  software.  The  executive  system  is  embodied  in  the  routines 
beginning  with  the  mnemonics  XQxxxx.  In  addition  to  the  pure  executive  system  routines,  the 
executive  initialization  routines  for  the  database  (DBINIT)  and  the  memory  manager  (HMINIT) 
are  also  located  in  this  code  block.  Finally,  the  general  initialization  routine  PREPAS  and  the 
MAPOL  compiler  software  are  considered,  for  the  purposes  of  the  Programmer’s  Manual,  to  be 
part  of  the  executive  system.  Those  routines  are  documented  in  Section  5. 

3.  The  DATABASE  code  block  contains  all  the  software  related  to  the  application  interface  to  the 
database  and  memory  management  systems  for  the  ASTROS  procedure.  This  software  is  further 
subdivided  into  five  groups  of  code  that  represent  the  application  interface  to  the  database  and 
memory  manager.  These  groups  are: 

a.  The  General  Utilities  that  comprise  the  databas".  application  interface  applicable  to  all 
database  entity  types.  These  routines  are  denoted  by  the  mnemonics  DBxxxx  and  are 
documented  in  Section  8.2. 

b.  The  Memory  Management  Utilities  that  comprise  the  application  interface  to  the  ASTROS 
dynamic  memory  manager.  These  routines  are  denoted  by  the  mnemonics  HJtxxxx  and  are 
documented  in  Section  8.3. 
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c.  The  Matrix  Utilities  that  comprise  the  database  application  interface  applicable  to  matrix 
entities.  These  routines  are  denoted  by  the  mnemonics  HXxxxx  and  are  documented  in 
Section  8.4. 

d.  The  Relation  Utilities  that  comprise  the  database  application  interface  applicable  to  rela¬ 
tional  entities.  These  routines  are  denoted  by  the  mnemonics  RExxxx  and  are  documented 
in  Section  8.5. 

e.  The  Unstructured  Utilities  that  comprise  the  database  application  interface  applicable  to 
unstructured  entities.  These  routines  are  denoted  by  the  mnemonics  UNxxxx  and  are 
documented  in  Section  8.6. 

4.  The  MACHINE  DEPENDENT  code  block  contains  all  the  software  in  the  ASTROS  system  that 
has  been  designated  machine  dependent.  This  software  supplies  the  interface  between  the  host 
computer  and  the  ASTROS  system.  It  is  further  subdivided  into  two  groups  of  code: 

a.  The  General  Utilities,  comprising  the  database  machine  dependent  code  used  throughout 
the  ASTROS  system.  These  routines  are  denoted  by  the  mnemonics  xxxxxx  and  are 
documented  in  Section  3.1.1. 

b.  The  Database  Utilities,  comprising  the  database  machine  dependent  code  used  primarily 
by  the  database  software.  These  routines  are  denoted  by  the  mnemonics  DBMDxx  and  are 
documented  in  Section  3.1.2. 

5.  The  UTILITIES  code  block  contains  all  the  machine  independent  application  utilities  developed 
for  the  ASTROS  system.  This  software  is  a  suite  of  functions  that  are  useful  in  many  places  in 
the  code.  They  have  therefore  been  formalized  to  the  extent  that  they  may  be  used  by  any 
ASTROS  application  routine.  The  majority  of  these  routines  are  denoted  by  the  mnemonics 
UTxxxx  with  exceptions  corresponding  to  those  in-core  utilities  that  came  from  COSMIC/NAS- 
TRAN.  These  are  documented  in  Section  6. 

6.  The  LARGE  MATRIX  UTILITIES  code  block  contains  the  utilities  developed  for  the  ASTROS 
system  to  operate  on  large  matrices  stored  on  the  ASTROS  database  (rather  than  matrices  stored 
in  memory).  This  software  comprises  a  suite  of  matrix  operations  that  have  been  formalized  to 
the  extent  that  they  may  be  used  by  any  ASTROS  application  routine  and  by  the  ASTROS 
executive  system.  There  is  no  consistent  naming  convention  for  these  routines  since  they  have 
been  derived  from  their  COSMIC/NASTRAN  counterparts.  The  utilities  are  documented  in 
Section  7. 

7.  The  APPLICATION  MODULES  code  block  is  the  largest  code  block  within  ASTROS.  It  contains 
the  engineering  and  application  modules  that  support  the  analysis  and  optimization  features  of 
the  ASTROS  system.  Each  of  these  modules  has  been  designed  to  be  independent  of  the  other 
application  modules  to  the  maximum  extent  possible.  Typically,  consistent  naming  conventions 
have  been  used  for  routines  within  each  module.  Because  of  the  disparate  code  resources  that 
were  used  in  the  development  of  ASTROS,  however,  no  globally  consistent  naming  convention 
was  adopted.  Section  5  documents  each  of  the  modules  in  the  application  library. 
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2.3.  CODE  COMMON  TO  ASTROS  AND  SYSGEN 


Since  some  machines  require  or  can  take  advantage  of  an  explicit  knowledge  of  which  routines 
are  needed  to  create  an  executable  image,  this  section  attempts  to  indicate  which  portions  of  the  source 
code  blocks  (as  grouped  in  Figure  3)  are  utilized  within  the  SYSGEN  program.  With  the  exception  of  the 
SYSGEN  code  block,  all  the  illustrated  code  blocks  are  used  by  the  ASTROS  program.  The  source  code 
blocks  that  are  needed,  in  whole,  or  in  part,  by  SYSGEN  are  (1)  the  SYSGEN  code,  (2)  the  DATABASE 
code,  (3)  parts  of  the  MACHINE  DEPENDENT  code,  (4)  some  of  the  UTILITIES  and  (5)  parts  of  the 
ASTROS  EXECUTIVE. 

Rather  than  write  and  maintain  separate  code  blocks  to  perform  similar  functions,  SYSGEN 
makes  use  of  the  suite  of  general  utilities  in  the  UTILITIES  CODE  BLOCK.  The  machine  dependent  code 
block  is  also  shared  between  ASTROS  and  SYSGEN. 

One  of  the  tasks  of  SYSGEN  is  to  compile  and  store  the  standard  executive  sequence  (written  in 
the  MAPOL  language)  onto  the  system  database.  Therefore,  the  SYSGEN  program  makes  use  of  the 
ASTROS  EXECUTIVE  code  block  to  supply  the  MAPOL  compiler.  In  addition,  the  SYSGEN  driver  must 
perform  the  executive  functions  to  initialize  the  memory  manager  and  the  database.  Therefore,  the 
MMX  NIT  and  DBINIT  routines  from  the  ASTROS  EXECUTIVE  code  block  are  also  used  by  SYSGEN. 
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3.  SYSTEM  INSTALLATION 


A  software  system  of  the  magnitude  of  ASTROS  requires  a  formal  installation  of  the  system  on 
each  host  computer.  For  ASTROS,  the  installation  process  can  be  broken  into  three  distinct  phases.  In 
the  first  phase,  the  ASTROS/host  interface  is  defined  and  the  proper  machine  dependent  code  is  written 
to  create  that  interface.  The  second  phase  involves  the  generation  of  the  executable  image  of  the  SYSGEN 
program  and  its  execution.  Finally,  the  ASTROS  executable  image  is  generated  using  the  outputs  from 
the  SYSGEN  program.  The  purpose  of  this  section  is  to  document  all  the  machine  dependent  code  in  a 
generic  manner  and  to  indicate  which  parameters  and  routines  are  most  likely  to  be  site  dependent  and 
which  are  truly  machine  dependent.  In  the  typical  case,  the  system  manager  at  each  facility  will  be  given 
the  machine  dependent  library  for  the  host  system  that  is  to  be  used.  For  completeness,  however, 
sufficient  detail  is  presented  to  allow  someone  familiar  with  the  host  system  to  write  a  new  set  of 
machine  dependent  code. 

Following  the  formal  documentation  of  the  machine  dependent  interface  is  a  discussion  of  the 
SYSGEN  program  and  its  inputs.  The  SYSGEN  program  is  important  in  that  it  provides  the  advanced 
analyst/user  with  a  mechanism  to  add  features  to  the  system.  It  is  also  important  for  system  installation 
in  that  part  of  its  output  is  required  before  the  executable  image  of  the  ASTROS  procedure  can  be 
generated.  Again,  in  the  typical  case  the  user  will  be  given  a  proper  set  of  SYSGEN  outputs  but  the 
utility  of  SYSGEN  in  increasing  the  capabilities  of  the  system  makes  its  complete  documentation  very 
useful  to  the  majority  of  ASTROS  users.  Finally,  a  brief  section  is  included  to  present  the  total  ASTROS 
installation  in  a  step  by  step  manner  to  give  an  overall  view  of  the  process. 

The  information  presented  in  these  sections  serves  as  a  guide  to  the  installation  of  ASTROS  on 
alternative  host  machines,  but  the  nature  of  the  machine  dependencies  make  it  impossible  to  anticipate 
all  contingencies  that  may  arise.  The  installation  of  the  ASTROS  procedure  on  a  new  host  computer  can 
therefore  be  a  complex  task  despite  the  relatively  small  number  of  machine  dependent  routines. 
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3.1 .  MACHINE  DEPENDENT  CODE 


The  machine  dependent  interface  has  been  designed  such  that  approximately  40  routines  are 
needed  to  complete  the  connection  between  ASTROS  and  the  host  system.  The  development  of  the 
machine  dependent  interfaces  can  be  done  in  a  straightforward  manner  on  most  machines  with  more 
complexity  required  for  sophisticated  interfaces  or  for  alternative  host  architectures.  The  typical  ASTROS 
user  will  not  be  willing  to  perform  any  but  the  most  rudimentary  duplication  of  the  standard,  supported 
installation  dependent  interface,  although  anyone  familiar  with  the  host  computer  system  could  accom¬ 
plish  the  task.  Installation  at  sites  using  machines  that  are  much  like  the  ones  already  supported  is  fairly 
simple,  although  even  the  installation  of  ASTROS  on  identical  host  machines  can  require  some  modifica¬ 
tion  to  the  machine  dependent  code  since  some  parameters  and  code  are  site  dependent  as  well  as 
machine  dependent. 

The  machine  dependent  code  is  separated  into  two  libraries:  the  general  library,  denoted  by 
names  starting  with  XX,  and  the  database  machine  dependent  library,  denoted  by  names  starting  with 
DBMD.  The  general  library  consists  of  timing  routines,  bit  manipulation  routines,  some  character  string 
manipulation  routines,  a  random  number  generator  and  a  BLOCK  DATA  subroutine  containing  a  number 
of  machine  and  installation  dependent  parameters.  The  timing  routines  and  the  random  number  gener¬ 
ator  are  site  dependent  in  that  each  facility  typically  has  a  library  of  such  routines.  The  BLOCK  DATA 
contains  such  parameters  as  the  open  core  size,  the  definition  of  logical  units,  output  paging  parameters 
and  other  site  dependent  parameters.  The  remainder  of  the  routines  are  very  simple  and  typically  do  not 
vary  substantially  from  site  to  site,  although  they  are  different  between  machines.  In  some  cases,  the 
XS-routines  are  written  in  standard  FORTRAN  and  are  in  the  machine  dependent  library  only  because 
some  host  systems  provide  special  routines  to  perform  these  tasks. 

The  database  machine  dependent  library  (DBMD)  is  much  more  complex  than  the  general  machine 
dependent  library.  The  complication  arises  because  of  the  flexibility  of  the  machine  dependent  interface 
and  because  of  the  nature  of  the  interface.  Unlike  the  xx  library,  the  DBMD  library  deals  with  file 
structures  and  I/O  to  the  host  system  and  with  memory  management.  These  issues  are  highly  machine 
dependent  and  are  further  complicated  because  the  translation  of  machine  independent  parameters  like 
file  names  to  the  actual  host  system  file  name  may  need  to  be  very  flexible  depending  on  the  nature  of  the 
local  host  system.  The  ASSIGN  database  entry  in  ASTROS  allows  the  user  to  enter  machine  dependent 
parameters  associated  with  the  data  base  file  attachment.  A  major  task  in  writing  the  DBMD  library  is  the 
definition  of  these  parameters  and  the  rules  for  their  use:  in  general  they  are  used  to  enable  the  user  to 
modify  the  default  file  attributes.  For  example,  block  sizes;  or  their  location  on  a  physical  device,  such  as 
disk  volume.  The  flexibility  inherent  in  the  machine  dependent  interface  can  cause  difficulties  in  writing 
the  DBMD  code,  however,  in  that  the  code  developer  may  find  it  hard  to  differentiate  those  aspects  of  the 
interface  that  are  free  to  be  redefined  from  those  that  are  required  by  ASTROS.  In  the  authors’  experi¬ 
ence,  however,  the  task  has  proven  to  be  tractable  for  all  host  systems  used  thus  far  by  using  the  existing 
routines  as  a  model.  The  reader  should  be  under  no  illusion,  however,  that  the  task  of  writing  the  DBMD 
machine  dependent  library  is  simple. 

The  following  sections  document  the  xx  and  dbmd  machine  dependent  libraries  in  a  machine 
independent  manner.  Each  routine  that  is  essential  to  the  ASTROS  interface,  its  calling  sequence  and  its 
design  requirements  is  listed.  It  is  very  important  to  appreciate  that  the  actual  machine  dependent 
interface  may  require  additional  routines  that  are  not  documented  in  these  sections.  The  only  routines 
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that  are  shown  here  are  those  that  are  referenced  by  the  machine  independent  portions  of  ASTROS.  By 
definition,  it  is  these  routines  that  constitute  the  machine  dependent  interface.  It  is  often  desirable  and 
sometimes  necessary  for  the  machine  dependent  code  to  call  other  machine  dependent  routines.  These 
internal  interfaces  are  not  documented  in  this  report  because  of  their  high  degree  of  dependence  on 
particular  host  machines  and/or  site  configurations.  It  is  completely  up  to  the  discretion  of  the  code 
developer  to  decide  whether  such  routines  are  desirable  and  what  tasks  they  should  perform.  In  fact, 
there  are  no  requirements  of  any  kind  for  the  machine  dependent  code  except  those  imposed  by  the 
definition  of  the  interface  (calling  sequence  and  design  assumptions).  It  is  that  very  flexibility  that  makes 
the  machine  dependent  code  generation  difficult. 

3.1 .1 .  General  Dependent  Code 

The  following  sections  document  each  of  the  general  machine  dependent  routines  contained  in  the 
XX  library.  These  routines  tend  to  be  highly  site  dependent  as  well  as  machine  dependent,  but  are 
relatively  straightforward  to  develop.  Their  functions  are  simple  and  do  not  deal  with  the  mqjor  machine 
dependencies  like  I/O  and  word  sizes. 
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Machine  Dependent  Utility  Module:  DOUBLE 

Entry  Point:  DOUBLE 

Purpose: 

Machine  dependent  logical  function  to  determine  the  machine  precision  as  one  of  single  or  double 
precision. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

DOUBLE  (  ) 

Method: 

double  returns  a  •  true  .  if  the  machine  precision  is  double  or  a  .  false  .  if  it  is  single.  ASTROS  then 
produces  all  matrix  entities  and  assume *  that  all  matrix  entities  are  of  the  machine  precision.  Mixing 
single  and  double  precision  matrices  is  not  supported  by  ASTROS  code.  DOUBLE  should  be  used  by  all 
application  modules  that  use  matrix  entities. 

Design  Requirements: 

1.  All  matrix  operations  must  be  either  single  or  double,  not  mixed. 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XZBCLR 

Entry  Point:  XXBCLE 

Purpose: 

Machine  dependent  integer  function  to  clear  a  bit  in  an  array. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

XXBCLR  (  ARRAY,  BIT  ) 

Method: 

The  bit  manipulation  routines  all  assume  that  the  BIT  identifier  can  vary  from  I  to  any  positive  integer. 
A  consistent  set  of  assumptions  on  the  correspondence  of  BIT  to  a  word/bit  combination  in  ARRAY  must 
be  made  for  all  bit  routines. 

Design  Requirements: 

1.  For  machine  independent  use,  application  program  units  should  size  array  based  on  32  or  fewer 
b»ts  per  word. 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXBD 

Entry  Point:  XXBD 

Purpose: 

A  bloclr.  data  subroutine  to  initialize  machine  or  installation  dependent  parameters. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence. 

None 

Method: 

The  xxbd  block  data  establishes  the  values  of  machine  dependent  constants.  These  parameters  include 

any  cons*  ant  that  may  be  needed  for  the  machine  dependent  library  as  well  as  the  following  installation 

or  machine  dependent  values  required  by  the  ASTROS  machine  independent  routines: 

(1)  The  size  of  the  open  core  common  block  /MEMORY/  in  single  precision  words. 

(2)  System  dependent  precision  terms  for  the  large  matrix  utilities  and  memory  management 

(3)  The  parameters  identifying  the  name  and  password  of  the  ASTROS  system  database.  These  must 
correspond  to  those  used  in  the  SYSGEN  program. 

(4)  The  number  of  bytes  and  bits  in  a  single  precision  word,  the  number  of  characters  that  will  be  stored 
in  a  hollerith  word  and  the  FORTRAN  format  statement  to  read  or  write  one  hollerith  word. 

(5)  The  set  of  "large"  and  "small"  numbers  for  the  machine,  including  a  large  real  number,  a  small  real 
number,  the  square  root  of  a  smell  real  number  and  the  largest  integer  value  supported  by  the  host 
system. 

(6)  The  installation  dependent  number  of  lines  per  page  and  the  maximum  number  of  output  lines  that 
will  be  used  by  the  ASTROS  page  utility,  OTPAGE. 

(7)  The  ASTROS  and  SYSGEN  version  and  release  identifiers. 

(8)  The  installation  dependent  set  of  logical  unit  numbers  identifying  the  read/write/punch  units  and 
the  unit  to  be  used  for  the  include  files,  intermediate  storage  of  the  executive  timing  summary  and 
the  queued  storage  of  the  error  messages. 

(9)  System  dependent  null  values  for  relational  entity  attribute  types 
Design  Requirements: 

1.  The  logical  units  specified  in  the  XXBD  block  data  must  not  conflict  with  those  identified  in  the 
database  machine  dependent  block  data  DBBD  for  the  database  files. 

Error  Conditions: 

none 


18 


Machine  Dependent  Utility  Module:  XXBSET 
Entry  Point:  XXBSET 


Purpose: 

Machine  dependent  routine  to  set  a  bit  in  an  array. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  XXBSET  (  ARRAY,  BIT  ) 

Method: 

The  bit  manipulation  routines  all  assume  that  the  BIT  identifier  can  vary  from  1  to  any  positive  integer. 
A  consistent  set  of  assumptions  on  the  correspondence  of  BIT  to  a  word/bit  combination  in  ARRAY  must 
be  made  for  all  bit  routines. 

Design  Requirements: 

1.  For  machine  independent  use,  application  program  units  should  size  array  based  on  32  or  fewer 
bits  per  word. 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXBTST 

Entry  Point:  XXBTST 

Purpose: 

Machine  dependent  logical  function  to  test  a  bit  in  an  array. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

XXBTST  (  ARRAY,  BIT  ) 

Method: 

The  bit  manipulation  routines  all  assume  that  the  BIT  identifier  can  vary  from  1  to  any  positive  integer. 
A  consistent  set  of  assumptions  on  the  correspondence  of  bit  to  a  word/bit  combination  in  ARRAY  must 
be  made  for  all  bit  routines. 

Design  Requirements: 

1.  For  machine  independent  use,  application  program  units  should  size  ARRAY  based  on  32  or  fewer 
bits  per  word. 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXCLOK 
Entry  Point:  XXCLOK 


Purpose: 

Machine  dependent  routine  to  return  the  time  of  day  as  a  character  string  and  as  a  number  of  seconds 
past  midnight. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence; 

CALL  XXCLOK  (  TIME,  ISEC  ) 

time  Character  string  containing  the  time  of  day  as  hh  :  mm  :  ss  (Character,  Out¬ 

put) 

ISEC  Integer  number  of  seconds  since  midnight.  (Integer,  Output) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXCPU 

Entry  Point.:  XXCPU 

Purpose: 

Machine  dependent  routine  to  retrm  the  elapsed  CPU  time  in  seconds. 

MAPQL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALI*  XXCPU  (  CPU  ) 

CPU  Number  of  seconds  of  CPU  time  used  since  the  job  started.  (Beal,  Output) 

Method: 

On  the  first  call  to  XXCPU,  the  utility  must  initialize  the  system  CPU  timer  and  return  0.0  elapsed 
seconds.  On  subsequent  calls,  the  elapsed  CPU  time  in  seconds  is  returned. 

Design  Rep  oirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXDATE 
Entry  Point:  XXDATE 


Purpose: 

Machine  dependent  routine  to  return  the  date  as  a  character  string  mh/dd/YY. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  XXDATE  (  TODAY  ) 

TODAY  Character  string  containing  the  date  as  MM/DD/YY.  (Character,  Output) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXFLSH 

Entry  Point:  XXPLSH 

Purpose: 

Machine  dependent  routine  to  flush  any  data  in  the  buffer  for  a  given  logical  unit. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  XXFLSH  (  LU  ) 

LTJ  The  logical  unit  number  of  the  file  whose  buffer  is  to  be  flushed.  (Integer, 

Input) 

Method: 

The  XXFLSH  routine  will  typically  be  a  return.  On  machines  that  support  the  ability  to  flush  the  I/O 
buffer  for  a  file,  however,  the  XXFLSH  routine  should  call  that  routine  to  flush  the  buffer  to  the  file. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXINIT 

Entry  Point:  XXINIT 

Purpose: 

Machine  dependent  routine  to  perform  general  machine  dependent  initialization  tasks. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  XXINIT 

Method: 

The  XXINIT  routine  is  typically  used  to  enter  machine  dependent  parameters  relating  to  error  handling 
by  the  host  machine,  the  initialization  of  the  machine  dependent  parameters  that  must  be  done  at  run 
time  on  certain  machines  and  performing  any  other  machine  or  installation  dependent  actions  that  may 
be  useful.  The  XXINIT  routine  is  called  by  the  ASTROS  main  driver  as  the  first  executable  statement 
of  the  ASTROS. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXITOS 
Entry  Point:  XXITOS 


* 


Purpose: 

Machine  dependent  routine  to  return  the  character  representation  of  an  integer. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  XXITOS  (  N,  V  ) 

N  Input  integer 

v  Output  character  string 

Method: 

This  routine  may  be  written  in  standard  FORTRAN  77  using  the  internal  file  feature  to  write  the  integer 
onto  the  character  string.  It  is  often  more  efficient  to  crack  the  integer  into  its  constituent  digits.  Some 
machines  have  local  utilities  that  may  be  used. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXLSFT 
Entry  Point:  XXLSFT 


Purpose: 

Machine  dependent  integer  function  to  shift  bits  to  the  left  in  an  integer  word. 

Function  Arguments: 

XXLSFT  (  INTI,  INT2  ) 

Method: 

The  machine  independent  use  of  this  function  requires  that  INT2  be  less  than  the  smallest  number  of 
bits  in  a  word  for  any  target  machine  (typically  32). 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXNOT 

Entry  Point:  XXNOT 

Purpose: 

Machine  dependent  integer  function  that  returns  the  complement  of  INTI. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

XXNOT  (  INTI  ) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module: 


XXOVFL 


Entry  Point:  XXOVFL 


Purpose: 

Machine  dependent  routine  to  test  for  floating  point  overflow  or  underflow  and  return  a  flag  denoting 
which  has  occurred. 

MAPOL  Calling  Sequence: 

None 


Application  Calling  Sequence: 

CALL  XXOVFL  (  J  ) 

j  Integer  value  returned  based  on  the  over/underflow  condition: 

■  1  floating  point  overflow  exists 

■  2  no  error  condition 

>  3  floating  point  underflow  exists 

Method: 

In  the  case  of  this  special  routine,  if  the  host  system  does  not  have  an  XXOVFL  type  of  routine,  it  is 
necessary  to  return  a  J«2  value  for  all  calls  to  XXOVFL.  In  this  case,  the  host  system  will  be  relied  upon 
to  indicate  the  occurrence  of  a  floating  point  error. 


Design  Requirements: 
None 


Error  Conditions: 
None 
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Machine  Dependent  Utility  Module:  XXXtAND 

Entry  Point:  XXRAND 

Purpose: 

Machine  dependent  function  that  returns  a  random  single  precision  number  between  0.0  and  1.0. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

XXRAND  {  ) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXRSFT 

Entry  Point:  XXRSFT 

Purpose: 

Machine  dependent  integer  function  to  shift  bits  to  the  right  in  an  integer  word. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

XXRSFT  (  INTI,  INT2  ) 

Method: 

The  machine  independent  use  of  this  function  requires  that  INT2  be  less  than  the  smallest  number  of 
bits  in  a  word  for  any  target  machine  (typically  32). 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXRTOS 
Entry  Point:  XXRTOS 


Purpose: 

Machine  dependent  routine  to  return  the  character  representation  of  a  real  number. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  XXRTOS  (  RSL,  STR  ) 

RBL  Input  real  number 

STR  Output  character  string 

Method: 

This  routine  may  be  written  in  standard  FORTRAN  77  using  the  internal  file  feature  to  write  the  real 
onto  the  character  string.  It  is  often  more  efficient  to  crack  the  real  into  its  constituent  digits.  Some 
machines  have  local  utilities  that  may  be  used. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  XXULNS 

Entry  Point:  XXULNS 

Purpose: 

Machine  dependent  routine  to  return  the  used  length  of  a  character  string. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  XXULNS  (  STR,  ULEN  ) 

str  Character  string  (Character,  Input) 

ULEN  The  position  of  the  last  nonblank  character  (the  first  character  in  the 

string  is  character  1).  (Integer,  Output) 

Method: 

The  xxulns  routine  may  be  written  in  standard  FORTRAN  77  using  the  LBN  function  to  return  the 
total  length  and  then  looking  backwards  for  the  first  nonblank  character.  Certain  hoBts  may  benefit 
from  a  machine  dependent  approach  when  byte  operations  are  expensive. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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3.1 .2.  Database  Dependent  Code 


The  following  sections  document  each  of  the  database  machine  dependent  routines  contained  in 
the  DBMD  library.  These  routines  tend  to  be  site  independent,  but  are  highly  machine  dependent.  Their 
development  on  a  new  host  system  can  become  quite  complex  depending  on  the  desired  sophistication  of 
the  interface.  These  routines  deal  with  file  structures  I/O  and  memory  management  as  well  as  certain 
CPU  critical  string  manipulation  functions. 
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Machine  Dependent  Utility  Module:  DBMDAB 

Entry  Point:  DBMDAB 

Purpose: 

lb  abort  the  execution  of  ASTROS  due  to  a  database  or  memory  management  fatal  error. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBMDAB  (  FLAG  ) 

FLAG  An  integer  input  denoting  whether  the  executive  termination  utility 

xqends  is  to  be  called  or  not. 

*  0,  call  XQENDS,  otherwise  stop 

Method: 

The  DBMDAB  routine  is  set  up  to  avoid  the  recursion  that  can  occur  due  to  the  termination  actions  taken 
by  the  xqends  termination  utility.  Since  the  database  and  memory  manager  are  calling  for  the  abort, 
the  xqends  routine’s  attempts  to  close  the  database  f  les  often  cause  the  DBMDAB  routine  to  be  called 
again.  Hence,  the  flag  argument  is  input  to  denote  that  the  abort  condition  is  such  that  any  attempts 
to  close  the  database  will  cause  recursion. 

Design  Requirements: 

None 

Error  Conditions: 

None 


35 


Machine  Dependent  Utility  Module:  DBMDAN 

Entry  Point:  DBMDAN 

Purpose: 

Machine  dependent  integer  function  that  returns  the  logical  AMD  of  INTI  and  INT2, 
MAPOL  Calling  Sequence: 

Non8 

Application  Calling  Sequence: 

DBMDAN  (  INTI/  XNT2  ) 

INTI  Input  integer 

XNT2  Input  integer 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  DBMDCH 
Entry  Point:  DBMDCH 


Purpose: 

lb  convert  a  character  variable  of  arbitrary  length  into  an  integer  array  with  four  hollerith  characters 
per  word. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBMDCH  (  CVAR,  I7AR,  LEM  ) 

CVAR  An  input  character  variable  of  arbitrary  length 

IVAR  The  output  integer  array  containing  the  hollerith  equivalent  of  CVAR 

lem  An  input  integer  denoting  the  number  of  characters  to  be  placed  in  IVAR. 

len  should  always  be  a  multiple  of  four,  this  routine  pads  with  blanks  as 
needed. 

Method: 

The  DBMDCH  routine  is  used  extensively  by  the  database  routines  to  convert  user  supplied  character 
variables  into  hollerith  integers  for  subsequent  processing.  It  is  critical  for  performance  that  this  routine 
be  efficient.  For  implementation  purposes,  it  must  be  assumed  that  the  input  character  string  can  be  of 
any  length,  but  the  output  hollerith  variable  must  always  have  four  characters  per  word.  Any  extra 
bytes  left  unused  are  filled  with  blanks. 

The  only  way  standard  FORTRAN  provides  to  convert  character  data  to  hollerith  data  is  with  an  incore 
file  operation  using  the  FORTRAN  read.  While  this  method  works  on  all  machines,  it  is  typically  very 
slow  and  causes  severe  performance  penalties.  This  method  can  be  avoided  in  most  cases  since  compilers 
typically  pass  two  arguments  for  every  character  variable  with  the  virtual  argument  containing  the 
character  length.  The  virtual  argument  either  follows  the  character  argument  directly  or  is  passed  at 
the  end  of  the  list  of  actual  arguments.  Knowing  this,  this  routine  can  usually  be  written  using  all  integer 
data  thereby  producing  much  faster  code. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  DBMDCX 
Entry  Point:  DBMDC1 


Purpose: 

To  perform  phase  1  of  database  configuration  initialization. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBMDC1  (  NWORD  ) 

NWORD  Number  of  words  required  in  DBNT  (Integer,  Output) 

Method: 

Phase  1  of  the  database  configuration  normally  involves  the  determination  of  default  values  for  the 
database.  The  values  that  can  be  changed  are  defined  in  the  /DBCONS/  common  block.  These  values 
can  be  hard  coded  in  this  routine,  hard  coded  in  the  DBBD  block  data  routine  or  read  from  a  configuration 
file. 

The  only  required  function  of  the  routine  is  to  return  the  number  of  words  in  the  system  dependent 
portion  of  the  DBNT. 

Design  Requirements: 

None 

Error  Conditions: 

None 

Entry  Point:  DBMDC2 
Purpose: 

Tb  perform  phase  2  of  database  configuration  initialization. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBMDC2  (  DBNT  ) 

dbnt  Database  name  table  (Integer,  Input) 
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Method: 


When  phase  2  of  the  database  configuration  is  performed,  the  DBNT  table  has  been  allocated  and  partially 
initialized.  This  routine  must  initialize  the  system  dependent  portion  of  the  table.  The  location  of  this 
data  can  be  found  as  follows. 


DBENTSD  =  Z  (DBNT  +  DBNSD) 

Z  ( DBENTSD  +xx)  =  machine  dependent  data 


It  is  also  the  responsibility  of  this  routine  to  make  sure  that  all  of  the  following  variables  >n  /DBOOlTt,/ 
have  legal  values. 

default  number  of  data  files 
maximum  number  of  data  files 
default  data  file  block  size 
default  index  file  block  size 
maximum  number  of  ENT  entries 
maximum  number  of  DBNT  entries 
maximum  number  of  NST  entries 
required  buffer  alignment 


DBDFIL 

DBMFIIi 

DBDEFD 

DBDEFI 

DBMAXE 

DBMAXD 

DBMAXN 

DBALON 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  DBMDDT 
Entry  Point:  DBMDDT 


Purpose: 

lb  return  the  time  and  date  in  hollerith  formats. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBKDDT  (  DATS,  TIME  ) 

DATS  Date  in  form  MM/DD/YY  (2  integer  words,  output) 

time  Time  in  form  HH  s  KM :  SS  (2  integer  words,  output) 

Method: 

This  subroutine  should  return  the  current  date  and  time  in  the  appropriate  locations.  Each  value 
returned  should  be  stored  in  two  integer  words  with  four  hollerith  characters  per  word. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  DBMDER 

Entry  Point:  DBMDER 

Purpose: 

lb  handle  machine  and  installation  dependent  error  conditions  for  the  database  and  memory  manager. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBM05R  (  ERROR  ) 

error  A  character  argument  containing  an  error  message  identifier. 

Method: 

The  DBMDER  routine  is  intended  to  be  used  in  two  ways.  The  first,  denoted  by  a  blank  character  string 
on  input,  is  to  activate  any  machine  dependent  error  handling.  This  is  the  interface  to  the  DBMDER  routine 
from  the  machine  independent  library.  For  example,  the  DBMDER  routine  typically  invokes  the  host 
dependent  mechanism  to  obtain  a  traceback  to  assist  in  locating  the  source  of  an  error.  The  second 
interface,  using  nonblank  character  strings  on  input,  is  intended  for  use  by  the  machine  dependent 
(DBMD)  library.  In  this  function,  the  DBMDER  routine  typically  writes  out  error  messages  identifying  the 
nature  of  the  (machine  dependent)  error  condition.  This  is  useful  for  error  checking  the  file  naming 
conventions,  host  I/O  limitations,  and  other  host  dependent  user  interfaces  to  the  ASTROS  system. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  dbkdfp 
Entry  Point:  DBMDFP 


Purpose: 

An  integer  function  to  reorder  the  bytes  in  an  integer  word. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

DBMDFP  (  INUM  ) 

INUM  An  integer  word  whose  bytes  are  to  be  reordered 

Method: 

9*}  C9r^a“  m®chfnes  Notably  VAX),  the  bytes  in  an  integer  word  are  stored  in  an  order  right  to  left. 
When  hoUenth  data  are  used,  this  feature  complicates  the  comparison  of  two  hollerith  words.  This 
routine  is  called  to  reorder  the  bytes  in  an  integer  word  to  be  left  to  right,  independent  of  the  storage 
format  on  the  machine.  On  machines  that  do  not  swap  bytes,  the  DBMDFP  function  value  should  be  set 
equal  to  the  INOM  value. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  DBMDHC 

Entry  Point:  DBMDHC 

Purpose: 

lb  convert  an  integer  array  with  four  holleritk  characters  per  word  into  a  character  variable  of  arbitrary 
length. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBMDHC  (  IVAR,  CVAR,  LEN  ) 

I  VAR  The  input  integer  array  containing  the  hollerith  characters. 

cvar  An  output  character  variable  containing  the  character  representation  of 

the  hollerith  IVAR. 

len  An  input  integer  denoting  the  number  of  characters  in  IVAR  to  convert 

and  place  in  CVAR.  LEN  should  always  be  a  multiple  of  four,  the  routine 
truncates  or  pads  with  blanks  as  needed. 

Method: 

The  dbmdhc  routine  is  used  extensively  by  the  database  routines  to  convert  hollerith  integer  into 
character  variables  for  subsequent  processing.  It  is  critical  for  performance  that  this  routine  be  efficient. 
For  implementation  purposes  it  must  be  assumed  that  the  output  character  string  can  be  of  any  length 
and  the  input  hollerith  variable  must  have  four  characters  per  word  as  generated  by  dbmdhc. 

The  only  way  standard  FORTRAN  provides  to  convert  hollerith  data  to  character  data  is  with  an  incore 
file  operation  using  the  FORTRAN  write.  While  this  method  works  on  all  machines,  it  is  typically  very 
slow  and  causes  severe  performance  penalties.  This  method  can  be  avoided  in  most  cases  since  compilers 
typically  pass  two  arguments  for  every  character  length.  The  virtual  argument  either  follows  the 
character  argument  directly  or  is  passed  at  the  end  of  the  list  of  actual  arguments.  Knowing  this,  this 
routine  can  usually  be  written  using  all  integer  data  which  produces  much  faster  code. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  DBMDHX 

Entry  Point:  DBMDHX 

Purpose: 

lb  dump  a  portion  of  memory  in  a  hexadecimal  or  octal  format. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALI.  DBMDHX  (  ARRAY,  LBN  ) 

array  Input  array  containing  data  to  be  dumped 

lbn  Number  of  single  precision  words  to  dump 

Method: 

If  a  database  error  occurs,  portions  of  the  in  core  control  tables  are  dumped  to  help  diagnose  the  problem. 
It  is  most  often  desirable  to  see  this  data  in  a  combined  hex/octal  and  character  format.  This  routine 
usually  dumps  the  desired  data  in  the  following  form: 

OFFH  OFFD  . hex/octal  data . character  data 

OFFH  -  hex/octal  offset  of  the  data  from  /MEMORY/ 

OFFD  -  decimal  offset  of  the  data  from  /MEMORY/ 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  DBMDIX 
Entry  Point:  DBMDIl 


Purpose: 

Phase  1  of  database  I/O  initdalizatioa 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBMDIl  (  NAME,  STAT,  RW,  USRPRM,  NFILE,  NWORD  ) 

name  Database  name  (Character,  Input) 

stat  Database  status  (old,  NEW,  TEMP,  SAVE,  or  perm)  (Input) 

RW  Read/write  flag  (RO,  WO,  R/W,  Input) 

dsrprm  User  parameters  (Character,  Input) 

NFILE  Number  of  data  files  in  database  (Integer,  Output) 

NWORD  Number  of  words  required  for  each  file  in  DBDB  (Integer,  Output) 

Method: 

Phase  1  of  the  I/O  initialization  is  responsible  for  determining  two  values:  the  number  of  data  files  in 
the  database  and  the  number  of  system  dependent  words  required  for  each  file  in  the  DBDB.  The  DBINXT 
call  is  provided  with  an  argument  called  USRPRM.  The  contents  of  this  character  string  are  completely 
machine  dependent  and  can  be  used  to  specify  any  special  processing.  Examples  of  these  fields  are 
provided  in  Section  1  of  the  User’s  Manual. 

The  most  difficult  function  of  this  routine  is  to  determine  the  number  of  data  files  for  a  database.  The 
following  ways  could  be  used. 

1.  If  the  database  has  a  status  of  NEW  or  TEMP,  the  number  of  data  files  is  either  the  default  of  entered 
via  the  usrprm. 

2.  If  the  database  has  a  status  of  old,  the  number  of  data  files  can  either  be  a  hard  coded  value  (usually 
1)  or  can  be  determined  by  opening  files  with  the  appropriate  names  until  an  open  fails. 

For  OLD  databases  this  routine  should  also  determine  the  index  and  data  file  block  sizes.  This  can 
usually  be  done  by  one  of  the  following  two  methods. 

1.  Inquire  as  to  the  physical  attributes  of  the  file  to  determine  the  block  sizes. 

2.  Do  a  sequential  read  of  the  first  block  of  the  index  file  and  extract  the  index  and  data  file  block  sizes 
that  are  stored  there. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Entry  Point:  DBMDI2 
Purpose: 

Phase  2  of  database  I/O  initialization. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBMDI2  (  DBDB  ) 

dbdb  Database  Descriptor  Block  (Integer,  Input) 

Method: 

When  phase  2  of  the  database  I/O  initialization  is  performed,  the  DBDB  table  has  been,  allocated  and 
partially  initialized.  This  routine  must  initialize  the  system  dependent  portion  of  the  table.  There  are 
also  several  words  in  the  machine  independent  portion  of  the  DBDB  that  must  be  initialized  for  each 
index  and  data  file.  The  following  code  shows  how  these  words  are  located. 


For  the  Index  file: 


|  DBDDBO  =  DBDB  +  DBDIFB 

- - 

For  the  Data  files: 

. 

DBDBO  =  DBDB  +  DBDDTA  +  (IFILE-1) *LENDDE 

For  all  files: 

DBDBSD  =  Z (DBDBO+DBDOSD) 

Z (DBDB+DBDIBS)  =  Index  file  block  size  in  words 
Z (DBDB+DBDDBS )  =  Data  file  block  size  in  words 
Z (DBDB+DBDMDF)  =  Maximum  number  of  data  files 
Z (DBDB+DBDONB)  =  Current  number  of  blocks  in  the  file 
Z ( DBDB+DBDOMB )  =  Maximum  number  of  blocks  allowed  in  the  file 
Z (DBDBSD+XX)  =  Machine  dependent  data _ 


This  routine  will  typically  do  any  physical  open  or  assign  calls  that  are  required  to  make  all  the  index 
and  data  files  for  this  database  available  for  processing. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  DBM&LC 

Entry  Point:  DBMDLC 

Purpose: 

An  integer  function  to  provide  the  memory  manager  with  an  address  of  a  character  memory  location  in 
particular  precisions. 

MAPQL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

DBMDLC  (  BASE,  PREC,  STAT  > 

BASE  An  input  character  array  whose  absolute  address  is  desired. 

PREC  An  input  integer  denoting  the  desired  precision  of  the  address 

=  0  byte  address 
*  1  word  address 
=  2  double  precision  word  address 

STAT  An  output  integer  value  that  is  nonzero  if  any  error  conditions  occurred. 

Method: 

The  routine  determines  the  absolute  address  of  BASE  and  modifies  the  offset  value  to  account  for  the 
precision  of  the  desired  address.  For  example,  the  VAX  machine  returns  the  byte  address  from  the  system 
utility  %locf.  Ib  obtain  the  word  address  for  the  VAX,  the  byte  address  is  divided  by  the  number  of 
bytes  per  word  (four).  A  check  is  made  to  determine  if  the  byte  address  is  an  even  multiple  of  four  and/or 
eight  to  check  the  single  and  double  word  alignment. 

Design  Requirements: 

1.  This  routine  is  identical  to  DBMDLF  except  that  the  BASE  array  in  this  routine  is  character  rather 
than  integer. 

Error  Conditions: 

1.  On  certain  machines,  there  is  a  requirement  that  the  memory  addresses  be  aligned  on  single  and/or 
double  word  boundaries.  This  routine  should  perform  these  checks  and  return  the  proper  STAT  value 
if  the  required  alignments  are  not  met: 
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Machine  Dependent  Utility  Module:  DBMDLF 

Entry  Point:  DBMDLF 

Purpose: 

An  integer  function  to  provide  the  memory  manager  with  an  address  of  an  memory  location  in  particular 
precisions. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

DBMDLF  (  BASK,  PRJBC,  STAT  ) 

BASK  An  input  integer  array  whose  absolute  address  is  desired. 

PRBC  An  input  integer  denoting  the  desired  precision  of  the  address 

*  0  byte  address 
»  1  word  address 

*  2  double  precision  word  address 

stat  An  output  integer  value  that  is  nonzero  if  any  error  conditions  occurred. 

Method: 

The  routine  determines  the  absolute  address  of  BASK  and  modifies  the  offset  value  to  account  for  the 
precision  of  the  desired  address.  For  example,  the  VAX  machine  returns  the  byte  address  from  the  system 
utility  %locf.  lb  obtain  the  word  address  for  the  VAX,  the  byte  address  is  divided  by  the  number  of 
bytes  per  word  (Pur).  A  check  is  made  to  determine  if  the  byte  address  is  an  even  multiple  of  four  and/or 
eight  to  check  the  single  and  double  word  alignment. 

Design  Requirements: 

1.  This  routine  is  identical  to  DBMDLC  except  that  the  BASK  array  in  this  routine  is  integer  rather  than 
character. 

Error  Conditions: 

1.  On  certain  machines,  there  is  a  requirement  that  the  memory  addresses  be  aligned  on  single  and/or 
double  word  boundaries.  This  routine  should  perform  these  checks  and  return  the  proper  STAT  value 
if  the  required  alignments  are  not  met: 


48 


Machine  Dependent  Utility  Module:  DBMDMM 
Entry  Point:  DBMDMM 


Purpose: 

Initializes  machine  dependent  parameters  for  the  memory  manager. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBMDMM  (  ICAWA,  IWLIC  ) 

icawa  An  output  integer  indicating  if  characters  are  word  aligned  on  the  host 

machine: 

a.  0  if  character  variables  are  word  aligned 
=  1  if  character  variables  are  not  word  aligned 


IWLIC 

Method: 

None 

Design  Requirements: 
None 

Error  Conditions: 
None 


An  output  integer  containing  the  number  of  characters  stored  in  a  single 
precision  word  on  the  host  system. 
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Machine  Dependent  Utility  Module:  DBMDOF 

Entry  Point:  DBMDOF 

Purpose: 

An  integer  function  to  return  a  FORTRAN  index  such  that  the  location  of  one  array  can  be  accessed  via 
another  array 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

DBMDOF  {  ARRAY 1,  ARRAYS  ) 

arrayi  One  FORTRAN  array  (Input) 

ARRAYS  Second  FORTRAN  array  (Input) 

Method: 

The  result,  DBMDOF,  is  a  FORTRAN  index  such  that  the  same  memory  location  is  referenced  by  ARRAYI 
(DBMDOF)  and  ARRAYS  { 1) .  In  the  DBOPEN  call,  the  user  provides  a  20-word  INFO  array.  The  last  10 
words  of  this  block  are  available  for  any  required  user  data.  These  10  words  can  be  modified  anytime 
up  to  the  dbclos  call  for  the  entity.  Since  the  INFO  array  is  not  passed  on  the  DBCLOS  call,  the  DBOPEN 
call  must  remember  where  it  is  for  later  access  by  the  DBCtiOS  call.  The  DBMDOF  function  allows  the 
database  to  remember  where  the  INFO  block  is  by  saving  its  location  relative  to  the  /MEMORY/  common 
block  at  open  time. 

The  actual  implementation  of  the  call  usually  requires  some  method  for  obtaining  the  actual  address 
for  a  subroutine  argument. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  DBMDOR 
Entry  Point:  DBMDOR 


Purpoae: 

Machine  dependent  integer  function  that  returns  the  logical  OR  of  INTI  and  INT2. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

DBMDOR  (  INTI,  INT2  ) 

INTI  Integer  (Input) 

INT2  Integer  (Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  dbmdrd 

Entry  Point:  DBMDRD 

Purpose: 

lb  read  a  block  from  the  database. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBMDRD  (  D3BD,  FILE,  BLK,  BUFHD  ) 

DBBD  Database  Descriptor  Block 

FILE  File  Number  (for  index  files,  FILE  »  0) 

BLK  Block  Number;  if  FILE  <  0  the  BLK  is  IBLK*DBMFIL  +  FILE 

bufhd  The  I/O  header  location 

Method: 

The  function  of  this  routine  is  to  read  a  block  from  the  database.  The  first  step  is  to  determine  the 
database  file  and  block  number  to  be  read,  the  following  code  will  perform  this. 

1F(FILE  _LT.  Q)  THEN 

IBLK  =  BLK/DBMFIL 
IFILE  =  BLK  -  IBLK*DBMFIL 

ELSE 

IBLK  =  BLK 
IFILE  =  FILE 

ENDIF  _ _ 


The  block  should  then  be  read  into  the  I/O  buffer  U3ing  the  appropriate  calls  for  the  target  system.  The 
machine  independent  dbdb  data,  referenced  from  dbdso,  and  machine  dependent  dbdb  data,  referenced 
from  DBDBSD  can  be  obtained  from  the  buffer  header.  The  number  of  words  to  transfer,  BLKSIZ,  is 
obtained  from  the  DBDB. 


IF (IFILE  .EQ.  0)  THEN 

DBDBO  =  DBDB  +  DBDIFB 
BLKSIZ  =  Z (DBDB+DBDIBS) 

ELSE 

DBDBO  =  DBDB  +  DBDDTA  +  ( IFILE- 1 ) *LENDDE 
BLKSIZ  =  Z (DBDB+DBDDBS) 

ENDIF 

BUFIO  =  Z (BUFHD+BFIOBF) 

DBDBSD  =  Z (DBDBO+DBDOSD)  _ 
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After  the  I/O  operation,  the  following  two  words  of  the  buffer  header  should  be  updates: 
Z(BUFHDrBFPBLK)  =  IBLK*DBMFIL  +  I FILE 

Z (BUFHD+BFD3DB)  =  DBDB _ 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  DBMDSI 

Entry  Point:  DBMDSI 

Purpose: 

lb  return  the  integer  represented  by  a  character  string. 

MAFOL  Calling  Sequence: 
hone 

Application  Calling  Sequence: 

CALL  DBMDSI  (  STK,  IVALUB  ) 

STR  An  input  character  string  containing  digits  and  signs  representing  an  in¬ 

teger  value. 

IVALUB  An  output  integer  variable  containing  the  integer  value  represented  by 

the  input  character  string 

Method: 

This  routine  is  typically  written  in  standard  FORTRAN,  but  may  be  available  as  a  host  system  utility. 
Design  Requirements: 

1.  A  leading  +  or  -  sign  is  permitted  as  are  all  the  decimal  digits.  Any  other  characters  are  illegal. 
Error  Conditions: 

1.  If  the  character  string  does  not  represent  an  integer,  no  warnings  are  given  and  IVALUB  is  set  to 
zero. 


I 
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Machine  Dependent  Utility  Module:  DBMDTR 

Entry  Point:  DBMDTR 

Purpose: 

lb  terminate  processing  of  a  database. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBMDTR  (  DBDB  ) 

DBDB  Database  Descriptor  Block  (Integer,  Input) 

Method: 

This  routine  is  called  at  program  termination  to  do  any  system  dependent  termination  processing  for 
each  database.  It  is  not  required  to  do  anything.  Typically  it  will  close  all  database  files. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Machine  Dependent  Utility  Module:  DBMDWR 
Entry  Point:  DBMDWR 

—  lTW r mum  I 


Purpose: 

lb  write  a  block  to  the  database. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CMiii  DBMDWR  (  BDFHD  ) 

BtTFHD  I/O  buffer  header  location  (Integer,  Input) 

Method: 

The  function  of  this  routine  is  to  write  a  block  to  the  database.  The  processing  is  similar  to  dbkdrd  and 
the  same  information  is  available  to  the  routine. 

When  writing  this  routine  one  special  case  must  be  considered.  Because  of  the  dynamic  way  in  which 
database  blocks  are  allocated  and  used,  it  can  never  be  assumed  that  the  database  blocks  are  appended 
in  sequential  order.  For  example  block  10  may  be  written  before  block  9.  If  this  situation  is  not  allowed 
on  the  target  system  then  this  routine  should  write  dummy  blocks  to  fill  any  gap  before  writing  the 
target  block.  The  contents  of  these  dummy  blocks  is  unimportant. 

After  the  I/O  operation,  the  "buffer  modified"  flag  in  the  buffer  header  should  be  set  to  zero, 
r  Z (BUFHD+BFMOD)  =0 


Also,  this  routine  should  maintain  the  word  in  the  machine  independent  portion  of  the  DBDB  which 
indicates  the  number  of  blocks  on  the  physical  file. 

f  Z  ( DBDBO+DBDONB )  =  MAX  (IBLK,  Z  (DBDBO+DBDONB)*)  j 


Design  Requirements: 
None 

Er  ror  Conditions: 
None 
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Machine  Dependent  Utility  Module:  DBMDZB 
Eufyy  Point:  DBMDZB 


Purpose: 

lb  find  the  first  zero  bit  in  a  word 
MAPOL  Calling  Sequence: 

None 


Application  Calling  Sequence: 

CALL  DBMDZB  {  WORD,  BITNO  ) 


word  Word  to  be  searched  for  a  zero  bit  (Integer,  Input) 

BIWNO  Bit  number  found.  It  will  be  a  number  ranging  from  1  to  31  if  a  zero  bit 

was  found.  It  will  be  -1  if  all  31  bits  are  on.  (Integer,  Output) 


Method: 


The  free  Block  Bit  Map  (fbbm)  uses  a  bit  to  represent  each  block  on  the  particular  database  file.  If  the 
bit  is  on,  the  block  is  allocated  and  if  the  bit  is  off,  the  block  is  unallocated.  Each  word  in  the  FBBM  is 
used  to  represent  31  blocks.  The  bits  are  numbered  as  follows: 


unused 


01 


02 


03 


31 


,nhis  bit  numbering  scheme  must  be  maintained  regardless  of  the  bit  numbering  scheme  of  the  target 
system. 

The  dbmdzb  routine  should  return  the  first  zero  bit,  starting  from  left  to  right.  If  all  bits  are  one,  then 
a  -1  is  returned.  This  function  typically  uses  the  FORTRAN  btest  function  (if  one  is  provided)  with 
appropriate  calculations  to  use  the  proper  bit  numbering  scheme. 

Design  Requirements: 

None 


Error  Conditions: 
None 
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3.2.  THE  SYSTEM  GENERATION  PROGRAM 


After  development  of  the  machine  dependent  source  code  for  the  target  host  machine,  the  next 
step  in  the  ASTROS  system  installation  is  the  assembly  of  the  executable  image  of  the  ASTROS  system 
generation  program,  SYSGEN.  The  libraries  that  must  be  linked  to  generate  this  program  have  been 
outlined  in  Section  2  of  this  manual  while  this  section  discusses  the  function  of  the  SYSGEN  program  and 
details  the  structure  of  its  inputs.  These  inputs  not  only  define  the  standard  ASTROS  system  but  are  also 
a  powerful  tool  for  an  advanced  user  to  expand  the  capabilities  of  the  system.  SYSGEN  represents  one  of 
the  most  useful  features  of  the  ASTROS  system  architecture  in  that  it  provides  for  automated  modifica¬ 
tion  of  many  of  the  procedure’s  capabilities  without  requiring  modification  of  any  existing  source  code. 

The  purpose  of  SYSGEN  is  to  create  a  system  database  (SYSDB)  defining  system  parameters 
through  the  interpretation  of  several  input  files.  Also,  a  FORTRAN  routine  is  written  by  SYSGEN  that 
provides  the  link  between  the  ASTROS  executive  system  and  the  application  modules  that  comprise  the 
run-time  library  of  the  procedure.  This  program  unit  is  then  linked  with  the  system  during  the  assembly 
of  the  ASTROS  executable  image.  The  resultant  procedure  makes  use  of  the  system  database  as  a  pool  of 
data  that  defines  the  system  at  run  time.  These  data  are: 

1.  The  contents  of  the  ASTROS  run-time  library  of  MAPOL  addressable  modules  including  both 
utility  and  application  modules.  Usually  delivered  as  moddbf.dat  or  KODDBF . DATA. 

2.  The  ASTROS  standard  executive  sequence  composed  of  MAPOL  source  code  statements.  Usually 
delivered  as  MAPOLSEQ .  DAT  or  MAPOLSEQ .  DATA. 

3.  The  set  of  bulk  data  entries  interpretable  by  the  system.  This  set  is  defined  through  the 
specification  of  bulk  data  templates  to  be  interpreted  by  the  ASTROS  Input  File  Processor  (IFP). 
Usually  delivered  as  TEMPLATE .  DAT  or  TEMPLATE .  DATA. 

4.  The  set  of  relational  schemata  used  by  the  executive  system  to  satisfy  the  declaration  of 
relational  variables  in  the  MAPOL  sequence  without  forcing  the  user  to  explicitly  define  each 
schema  at  run  time.  Usually  delivered  as  RELATION . DAT  or  RELATION.  DATA. 

5.  The  set  of  error  message  texts  from  which  the  UTMWRT  system  message  writer  utility  builds  error 
messages  at  run  time.  Usually  delivered  as  SEP_rmsg.DAT  or  serrmsg.data. 

There  is  an  input  file  for  each  of  these  data  which  is  interpreted  by  SYSGEN  and  used  to  write 
data  to  SYSDB  in  particular  formats.  These  database  entities  are  then  used  by  the  ASTROS  executive 
system,  application  modules  and  utilities  to  perform  certain  functions.  Since  these  program  units  are 
designed  to  interpret  the  set  of  data  that  are  present  in  the  SYSDB  entities,  they  are  flexible  in  that 
virtually  any  changes  to  the  set  of  data  can  be  accommodated  without  modification  of  the  software  that 
uses  the  data. 

The  following  sections  each  contain  a  description  of  a  SYSGEN  input  file  and  of  the  SYSDB 
database  entities  that  are  filled  with  the  corresponding  data.  These  input  files  contain  the  definition  of 
the  system  as  developed  for  the  ASTROS  procedure.  The  advanced  user  may,  through  the  appropriate 
changes  to  these  inputs,  add  new  rr  jdules,  add  new  error  messages  that  may  be  useful  as  part  of  the 
additional  module(s),  add  new  bulk  data  inputs,  add  new  relational  schemata  to  those  that  exist  or  add 
new  attributes  to  an  existing  schema.  Finally,  the  standard  solution  algorithm  itself  can  be  modified, 
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either  to  include  (as  a  permanent  modification)  a  new  feature  or  to  modify  an  existing  capability.  The 
advanced  user  is  cautioned,  however,  that  the  standard  sequence  represents  a  very  tightly  interwoven  set 
of  functions  and  any  changes  should  be  carefully  considered  for  thei”  ramifications  on  the  multidiscipli- 
naiy  features  of  the  system  as  it  is  currently  defined. 

3.2.1.  Functional  Module  Definition 

The  functional  modules  form  the  computational  heart  of  the  ASTROS  system.  A  sequential  file 
contains  character  data  records  that  define  the  following  information  for  each  module: 

1.  The  name  of  the  module 

2.  The  number  of  formal  parameters 

3.  If  the  module  is  a  function  or  a  procedure 

4.  The  type  of  each  formal  parameter 

5.  FORTRAN  code  lines  defining  the  module  call 
The  purpose  of  these  data  is  three-fold: 

1.  lb  provide  the  names  of  modules  that  are  a  part  of  ASTROS 

2.  lb  allow  the  validation  of  module  calls  including  type  checking  of  the  input  parameters 

3.  lb  define  the  way  in  which  the  results  of  a  module  are  used  and  to  provide  the  actual  FORTRAN 
link  to  activate  a  module 

The  format  used  to  provide  these  data  is  described  in  the  following  section 

3.2.1 .1  The  File  Format 

The  module  definition  file  is  organized  as  a  sequence  of  module  entries. 

MODULE (1)  ENTRY 
MODULE (2)  ENTRY 


Each  module  entry  has  the  following  form: 


MODNAME,  NPARM 

(A8 , 14 ) 

MOOT Y PE,  PARMTYPE (I) 

(2014) 

FORTRAN  LINES 

(A80) 

END 

(A8) 

where  the  first  line  consists  of  modname  and  NPARM  and  the  second  line  consists  of  KODTYPB  and  the  first 
19  parktypbs.  The  parmtypes  continue,  20  per  line,  on  subsequent  lines,  as  required  to  supply  NPARM 
PARMTYPE8. 
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The  lines  following  the  pabktypes  consist  of  FORTRAN  code  (including,  but  not  requiring, 
comments  or  blank  lines)  which  implements  the  module  interface  to  MAPOL. 

The  last  line  of  a  module  entry  is  the  word  END  starting  in  column  1. 


MCDNAME 
HP  ARM 

MODTYPE 

PAHMTYPH 


is  the  module  name  as  it  appears  in  MAPOL;  1  to  8  characters  beginning 
with  a  letter.  The  name  is  left-justified  in  an  8-character  field, 
is  the  number  of  formal  parameters  in  the  calling  list  of  the  module.  This  is 
a  right-justified  integer  in  a  4-digit  field.  There  is  a  limit  of  60  parameters, 
is  a  four-digit  code  for  the  module  type: 

100  means  the  module  is  a  function  with  a  fixed  number  of  parameters 

101  means  the  module  is  a  function  with  a  variable  number  of  parameters 

102  means  the  module  is  a  procedure 

The  declared  type  of  each  parameter  in  the  calling  list  selected  from  the 
following  codes,  each  a  four-digit  integer: 

1  Integer 

2  Real 


8  Complex 
4  Logical 
6  Not  Used 

6  Not  Used 

7  Relational  Entity 

8  Matrix  Entity 

9  Unstructured  Entity 

10  Real,  Integer,  or  Complex 

If  the  pahmtype  is  entered  as  a  negative  value,  the  parameter  is  optional.  Note  that  character 
PARMTYPEs  are  not  supported. 

Procedures 

For  procedures,  a  call  is  made  to  the  ASTROS  name  with  a  parameter  list  having  symbolic 
arguments  of  the  correct  types.  For  example,  if  a  module  has  the  following  parameters  (in  order) 
with  the  specified  data  types: 

3  Integers 
1  Logical 
1  Integer 
1  Relation 
1  Integer 
1  Optional  integer 

1  Optional  matrix 

1  Matrix 
1  Optional  matrix 
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1  Logical 
1  Matrix 

1  Optional  matrix 

2  Matrices 

1  Unstructured 

2  Optional  matrices 

1  Optional  logical 

2  Optional  matrices 

1  Optional  unstructured 

then  the  call  to  this  routine  is  coded  as: 


AROSNSDR  23 

1C2  1  1  1  6  1  7  1  -1  -8  8  -8  4  8  -8  8  8  9  -8 

-8 

-4  -8  -8  -9 

C 

C  PROCSSS  'AROSDR'  KODOTJS  -  SAXKO  CONS'TRAIK?  8KH8.  DRIVXR 
C 

CALL  AROSDR  «  »(!),.  19(3),  IP(3>,  LP{4),  IP(5),  IP(6),  XP(7), 

1  1P{8) ,  K?(9>,  BP(10),  KP(ll),  LP (12) ,  EP(13), 

2  IP  (14)  r  BP(15),  SP(1S),  IP  ( 17 ) ,  BP  ( 18 ) ,  XP(19) , 


The  subscripted  array  elements  are  used  by  the  ASTROS  executive  to  pass  the  actual  parameter 
values.  The  subscripts  must  correspond  to  the  order  of  the  arguments  in  the  MAPOL  calling  list.  The 
following  array  names  are  used: 

IP  -  Integer  Parameter 
RP  -  Real  Parameter 
CP  -  Complex  Parameter 
LP  -  Logical  Parameter 
EP  -  Entity  name 

This  method  passes  only  scalar  parameters  to  the  FORTRAN  driver.  No  mechanism  is  available  to  pass 
FORTRAN  arrays. 

Functions 

For  a  function,  the  resultant  value  is  returned  to  MAPOL  on  the  execution  stack.  To  accomplish 
this,  the  programmer  must  assign  the  numeric  function  result  to  the  FORTRAN  variables  IOUT,  ROUT, 
and  cour  that  define  the  number  to  the  executive.  This  is  analogous  to  a  function  in  FORTRAN,  in  which 
the  value  must  be  assigned  to  the  function  name  within  the  function  unit. 
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A  numeric  value  in  defined  as  follows: 


IOOT  ( 1 ) 

Variable  type  key  with  the  same  definitions  as  in  parmtype 

IOOT (2, 3)  or 

ROOT (2,3)  or 

COOT 

Contain  the  actual  integer,  real  or  complex  variable  value.  These 
arrays  are  all  equivalenced: 

If  the  value  is  integer,  only  IOOT  <  2 )  must  be  defined.  If  the  value  is  real,  only  ROOT*  ( 2 )  must  De  defined. 
If  the  value  is  complex,  then  either  COOT  must  be  defined,  or  ROOT(2)  and  ROOT {3  >  must  be  defined. 
What  is  important  is  that  the  data  in  the  second  and  third  words  be  consistent  with  the  type  in  IOOT  ( 1 ) . 

Further  if  the  function  operation  depends  on  the  types  of  arguments  (as  do  the  FORTRAN  generic 
functions,  e.g.  MAX,  SIN),  the  array 

|  TP ( I ) ,  1=1,  NPARAM 

may  be  read  in  the  module  definition  code  to  determine  the  type  of  argument  passed.  The  parmtype 
definition  should  then  be  10  to  allow  any  type  to  be  passed.  TP  uses  the  same  definitions  as  parmtype, 
except  the  actual  type  of  the  argument  is  stored.  In  other  words,  TP  contains  a  1,  2,  or  3  in  the  location 
associated  with  type  10  parameters,  depending  on  the  actual  type  passed  in  the  current  call. 


For  example,  if  the  sine  function  is  desired,  the  following  module  definition  would  be  used: 


SIN 

1 

100 

10 

!  c 

c 

SIN  -  RETURN  THE  SINE  OF  THE 

ARGUMENT 

C 

IF  ( 

TP ( 1 )  .LE.  2  )  THEN 

I OUT ( 1 )  =  2 

IF  (  TP ( 1 )  .EQ.  1  )  RP ( 1 ) 
ROUT ( 2 )  =  SIN(RP(1) ) 

ELSE 

I OUT ( 1 )  =  3 

COUT  =  SIN (CP (1)) 

ENDIF 

=  IP(1) 

END 

3.2.1  <2  SYSGEN  Output  for  Modules 

The  data  defined  by  the  module  file  are  processed  and  the  results  are  stored  on  the  system 
database  in  two  entities.  The  first  is  a  relation  called  KODINDBX.  This  relation  has  two  attributes:  the 
first,  MODLNAME,  is  the  module  name  and  the  second,  ARGPONTR,  is  a  pointer  to  the  second  entity.  This 
second  entity  is  called  modlargs.  Each  record  of  this  unstructured  entity  contains  the  MODTYPE  and 
PARMTYPE  data  from  the  module  definition  file  for  a  particular  module.  Additionally,  the  output  of 
SYSGEN  includes  a  FORTRAN  subroutine  called  XQDRiv.  This  routine  is  the  module  driver  for  the 
ASTROS  execution  monitor.  It  must  be  compiled  and  linked  into  the  system  when  adding  or  changing 
module  definitions. 
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3.2.2.  Standard  Solution  Algorithm  Definition 


The  standard  multidisciplinary  solution  algorithm,  in  the  form  of  MAPOL  source  code  state¬ 
ments,  is  contained  in  a  sequential  file.  The  SYSGEN  program  reads  this  file  and  compiles  a  standard 
sequence.  The  results  of  the  compilation  are  stored  on  the  system  database  in  the  form  of  two  relations 
and  an  unstructured  entity.  The  first  relation  is  called  &MAPMEM  and  has  three  attributes:  address, 
vartype,  and  CONTENT.  This  relation  stores  the  execution  memory  map  for  the  standard  MAPOL  se¬ 
quence.  address  is  an  integer  containing  the  address  of  the  variable,  vartype  is  an  integer  denoting  the 
variable  type  and  CONTENT  is  a  two-word  integer  array  containing  the  current  value  of  the  variable. 

The  second  relation  output  from  the  compilation  of  the  standard  sequence  is  called  WtAPCOD  and 
has  three  attributes:  INSSSQ,  OPCODE,  and  ARGUMENT.  This  relation  contains  the  ASTROS  machine 
instructions  that  represent  the  compiled  MAPOL  sequence.  INSSEQ  is  an  integer  containing  the  instruc¬ 
tion  sequence  number,  OPCODE  is  the  machine  operation  code  to  determine  the  action  to  be  taken,  and 
ARGUMENT  is  the  argument  to  the  operation  -  either  a  memory  address  of  an  immediate  operand. 

The  final  output  from  the  standard  algorithm  definition  is  not  directly  related  to  the  compilation 
of  the  sequence.  It  is  a  relation  called  ftMAPSOU  containing  the  standard  sequence  source  code  statements 
verbatim.  This  is  stored  on  the  system  database,  allowing  the  user  to  edit  the  standard  sequence  to 
generate  a  new  MAPOL  program  which  directs  the  ASTROS  procedure.  The  relation  has  two  attributes: 
LINENO  and  source,  lineno  is  an  integer  containing  the  line  number  and  source  is  a  string  attribute 
containing  the  80-character  source  code  line. 

3.2.3.  Bulk  Data  Template  Definition 

The  ASTROS  bulk  data  decoding  module  (IFP)  is  driven  by  templates  that  are  stored  on  the 
system  database  during  system  generation.  The  template  format  for  IFP  was  adopted  to  allow  for  easy 
installation  of  new  bulk  data  entries  and  for  easy  modification  of  existing  bulk  data  entries.  The  sequen¬ 
tial  file  used  by  SYSGEN  contains  the  bulk  data  templates  for  all  the  bulk  data  inputs  defined  to  the 
ASTROS  system  in  arbitrary  order. 

3.2.3.1  The  File  Format 

The  template  definition  file  has  the  following  format: 

NLPTMP  (18) 

TEMPLATE  1 
TEMPLATE  2 


MAXSET  is  the  maximum  number  of  template  sets  used  to  define  one  bulk  data  input.  Currently, 
this  value  is  five.  NLPTMP  is  the  number  of  lines  in  each  template  set.  Currently  there  are  six  lines  in 
each  set.  A  bulk  data  template  therefore  consists  of  1,2, 3, . .  .MAXSET  template  sets,  each  of  which 
consist  of  NLPTMP  template  lines  which  define  the  structure  of  the  input  entry.  The  definition  includes  the 
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field  size,  the  field  label,  the  field  data  type,  the  field  defaults,  the  field  checks,  the  field  database  loading 
position  and,  if  necessary,  a  list  of  relational  attributes.  The  structure  of  the  template  set  is  as  follows: 

BULK  DATA  ENTRY  LABEL  ’ 

FIELD  DATA  TYPES 
DEFAULT  VALUES 
ERROR  CHECKS 
FIELD  LOADING  POSITION 
DATABASE  ENTITY  DEFINITION 


A  typical  bulk  data  entry  template  is: 


CQUAD4 

i 

1  HID 

IPID 

101 

102 

103 

104 

IT* 

IZOI? 

ICONT 

i 

CHAR 

INT 

INT 

INT 

INT 

INT 

INT 

INT/RKALRKAL 

CHAR 

DKFA0LT 

KID 

0. 

0. 

CHICKS 

or  o 

<JT  0 

OT  0 

UO  2 

00  3 

00  4 

OT  0 

1 

2 

3 

4 

5 

S 

7 

9 

CQ0AD4 

KID 

PID1 

GRXD1 

ORID2 

0RID3 

GRID4 

CID1 

THETA 

+CQ0AD4  1 

I 

1 

1 

TXAX 

ITl 

|T2 

IT3 

IT4 

1 

i 

CHAR 

REAL 

RXAL 

REAL 

RIAL 

RIAL 

DXFA0LT 

1.E4 

CHICKS 

OX  0. 

OX  0. 

OK  0. 

OB  0. 

OX  0. 

10 

11 

12 

13 

-14 

orrsTO  ikax 

THICK1 

THICK.’. 

THICK3 

THICK4 

The  LABEL  Template  Set  Line 

The  first  seven  columns  of  the  first  template  set  line  define  the  name  of  the  input  data  entry.  The 
eighth  column  is  reserved  for  a  field  mark, "  I ".  Columns  9  through  72  define  the  field  labels  and  these  are 
separated  by  the  field  mark  "  I ".  Columns  73  through  79  indicate  to  the  decoding  routines  if  a  continu¬ 
ation  card  is  supported  for  this  entry.  On  the  first  template  set’s  LABEL  line  (the  template  set  for  the 
parent  line  of  the  bulk  data  entry),  the  character  string  CONT  indicates  that  a  continuation  line  is 
supported.  Otherwise,  these  columns  are  ignored  and  a  continuation  will  not  be  allowed  for  the  entry 
defined  by  this  template.  A  continuation  template  set’s  LABEL  line  differs  from  the  parent  template  in 
that  the  character  string  BTC  can  be  used  in  columns  73  through  79  of  the  continuation  template  set’s 
label  line  to  indicate  an  open  ended  entry  having  a  repeating  continuation.  In  this  case,  the  same 
continuation  template  will  be  used  to  decode  all  remaining  continuation  entries.  A  constraint  on  continu¬ 
ation  entries  is  that  the  input  must  extend  to  the  third  field  (the  second  data  field).  This  is  a  restriction 
imposed  by  free  format  input.  Also,  note  that  ALL  template  set’s  LABEL  lines  must  have  a  field  mark  in 
column  80  to  end  the  line. 

The  FIBLD  DATA  TYPE  Template  Set  Line 

The  pibld  data  typb  Template  Set  Line  defines  the  types  of  data  that  are  allowed  for  each 
field.  Possible  data  types  include:  blank,  I  NT  (integer),  REAL  (real),  CHAR  (character),  INT/RHAL  (integer 
or  real),  INT/CHAR  (integer  or  character),  and  RBL/CHAR  (real  or  character)  The  data  type  definition 
characters  (i.e.,  INT)  must  be  left  justified  in  the  fields. 
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The  DB fault  Template  Set  Line 


Tne  default  template  set  line  defines  the  default  values  of  the  fields.  If  the  input  data  entry  has 
an  empty  field,  the  default  value  will  be  used  as  the  input.  All  values,  like  the  data  types,  must  be  left 
justified  in  the  fields.  Three  special  cases  for  default  values  have  been  incorporated  into  the  decoding 
routines.  The  first  is  the  case  of  a  special  user  input  entry  to  define  the  defaults  for  a  template.  In  this 
case  the  user  supplied  values  will  be  substituted  for  the  normal  default  values.  The  BAROR  and  GRDSET 
entries  are  examples  of  special  inputs  used  to  define  the  defaults.  The  addition  e>f  any  other  special  inputs 
like  these  requires  program  changes  in  routines  IPPBD,  BDMBRG,  and  IFPDBC.  Another  special  case  is  in 
the  referral  to  another  field  of  the  same  template  to  obtain  the  default  value.  Referral  values  can  exist  for 
all  data  types  except  character  (CHAR)  data.  In  the  case  of  a  default  referral,  the  current  template  set 
label  line  is  searched  for  the  label  referred  to  and,  if  the  label  string  is  not  found,  all  other  template 
sets,  starting  at  the  parent  template  set,  are  searched  for  the  string.  When  the  string  is  found,  the 
corresponding  entry  field  is  decoded  to  obtain  the  default  value.  An  example  of  a  referral  is  the  PID  field 
of  the  CQUAD4  card  template.  The  third  special  case  for  defaults  is  the  use  of  a  multiplier  for  an  integer 
default  referral.  This  is  only  valid  for  integer  type  data  and  the  presence  of  a  multiplier  is  defined  by  an 
asterisk  For  example,  3*NDN,  where  NDN  is  the  label  associated  with  another  integer  data  field. 

The  BRROR  CHECK  Template  Set  Lin  e 


The  ERROR  CHECK  template  set  line  directs  data  checking  for  the  decoded  fields.  Each  error  check 
specifies  both  the  type  of  check  and  the  check  value.  The  available  check  types  depend  on  the  data  type 
(for  example,  Integer,  Real,  or  Character).  Checks  that  are  currently  encoded  are  Bhown  in  Table  1. 

If  additional  checks  are  needed,  subroutine  INTCHK  must  be  modified  for  integer  checks,  RELCHK 
must  be  modified  for  real  checks  and  chrchk  must  be  modified  for  character  checks. 


When  two  check  values  Eire  needed,  as  for  the  IB  and  EB  checks,  the  first  is  located  cn  the  ERROR 
CHECK  template  set  line  and  the  second  is  located  in  the  same  coromn  position  on  the  FIELD  LOADING 
POSITION  line. 

The  FIELD  LOADING  POSITION  Template  Set  Line 

The  field  loading  position  template  set  line  is  used  to  place  the  converted  data  into  the 
database  loading  array.  The  sequence  of  the  numbering  is  dependent  on  three  conditions.  The  first  is  the 
existence  of  CHAR  data  on  the  card.  In  this  CEise,  two  hollerith  single  precision  words  will  be  used  to  store 
an  eight  character  input  and  the  numbering  must  account  for  the  two  words.  The  second  condition  is  the 
sequence  of  the  attribute  list  for  a  relational  bulk  database  entity.  In  this  case  the  loading  sequence  is 
determined  by  the  sequence  of  the  attribute  list.  The  third  condition  occurs  when  a  multiple  data  type 
field  is  present,  (e.g.,  REL/CHAR).  In  this  case  the  first  variable  type  is  loaded  at  the  given  value  and  the 
second  variable  type  is  loaded  in  the  next  word(s).  Again  this  must  be  accounted  for  in  the  numbering 
sequence.  Finally,  when  a  negative  integer  value  is  given  as  the  loading  position,  the  database  loading 
array  will  be  loaded  onto  the  database  if  input  errors  have  not  occurred. 

The  DATABASE  ENTITY  DEFINITION  Template  Set  Line 


The  database  entity  DEFINITION  template  set  line  names  the  database  entity  to  be  loaded 
in  the  first  eight  columns  of  the  parent  template  set,  and  the  database  attribute  list  ror  relational  entities 
'’Columns  9-72),  of  the  parent  template  set.  Column  80  is  reserved  for  a  map-end  character  ($).  The 
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4 

Tabid  1.  Bulk  DataTemplate  Error  Checks 


CHECK 

TYPE 

DATA 

TYPE 

MEANING 

DTYPB 

Char 

MPREC 

Char 

Matrix  precision  for  DMI  and  DMIG  entries 

NFORM 

Char 

Matrix  form  for  DMI  and  DMIG  entries 

HT3TIH 

FFT2 

Char 

EgBEHSMI 

KAS3F 

Char 

Mass  matrix  form  option  for  the  MFORM 
entry 

KTYPL 

Char 

Element  name  for  the  ELEMLIST  and 
DCONTHK  entries 

CCI 

int 

Material  property  defaulting  check  for  the 
ROOM  P  entry 

CCRl 

Real 

Laminae  thickness  defaulting  check  for 
the  PCOMP  entry 

CCR2 

Raal 

Laminae  orientation  angle  defaulting 
check  for  the  PCOMP  entry 

CCR3 

Real 

Laminae  orientation  angle  and  thickness 
defaulting  check  for  PC0MP1  and 
PC0MP2  entry 

QTZOB 

Int .Real 

Greater  than  zero  or  blank 

OBZOB 

Int, Real 

Greater  than  or  ecual  to  zero  or  blank 

ULC 

Int 

IUST,  ILST,  and'or  ICAM  Check  for  the 
AIRFOIL  entry 

IAMCHK 

Int 

DCONLAM/DCONLMN  laminate  defini¬ 
tion  check 

PLYNOR8 

Int 

DCONLAM/DCONPMN  ply  definition 
check 

NEBLK 

Char 

Not  equal  to  blank 

ETYPC 

Char 

Element  name  for  the  DCONFTP  and 
DCONTWP  entries 

PTYPC 

Char 

Property  name  for  the  DCONFTP  and 
DCONTWP  entries 

ETYPS 

Char 

Element  name  for  the  DCONEP  and 
DCONVM  entries 

PTYPS 

Char 

Property  name  for  the  DCONEPP  and 
DCONVM  P  entries 

STYPK 

Char 

Control  surface  symmetry  type 

TRIM 

Char 

TRIM  type 

VTA 

Char 

UM  flap  for  RBEi  entries 

TRMACC 

Char 

Acceleration  label  check  for  DCONSCF 
entry 

SCFPRM 

Char 

Parameter  label  check  for  DCONSCF  en- 
M _ 

SCFUNIT 

Char 

Unit  label  check  for  DCONSCF  entry 

VTYPE 

Char 

Velocity  type  check  for  DCONFLT  entry 

DCNTYP 

Char 

l 

Constraint  type  check  for  DCONLIST  en- 
JY _ 

FLTFIT 

Char 

Curve  fit  type  check  for  FLUTTER  entry 

TjAMCHK 

Char 

DCONLAM/DCONLMN  laminate  check 

CHECK 

TYPE 

DATA 

TYPE 

MEANING 

blank 

all 

No  check 

GT 

int, Real 

Greater  than 

GE 

Int, Real 

Greater  than  or  equal 

NS 

Int, Real 

Not  equal 

LT 

Int, Real 

Less  than 

Z.B 

Int, Real 

Less  than  or  equal 

KQ 

All 

Equal 

EB 

mt.Real 

Exclusive  in  between 

IB 

Int, Raal 

Inclusive  in  between 

BOR 

int, Real 

Either  or 

GEP 

Int, Real 

Greater  than  or  equal  to  the  previous 
value 

no 

Int 

Unique  grid 

BOG 

Int 

COMP 

int 

Aset  of  component  numbers 

MID3 

Int 

PSHELL  MID3  matenal  check 

MIDI 

Int 

PSHELL  M!D4  material  check 

SA 

Int 

SPCADD,  MPCADD  combination  check 

BIGG 

Int 

Grid  check  on  the  EIGI  family  of  input 
entries 

'  BIGC 

Int 

Component  check  on  the  EIGI  family  of 
input  entries 

112 

Int 

MATG 

Int 

E  and  G  chock  on  the  MAT1  entry 

HU 

Real 

Check  E,  G  and  NU  for  the  MAT1  entry 

IDES 

Real 

Design  variable  range  check 

F.T. 

Char 

Failure  theory  for  the  PCOMP  entry 

YORN 

Char 

Yes  or  No 

PTYP 

Char 

ETYP 

Char 

Element  type  for  the  ELIST  entry 

NORM 

Char 

Normalization  method  for  the  EIGi  family 
of  input  entnes 

CMBTB 

Chrr 

Solution  method  for  the  EIGC  entrz 

RMETH 

Char 

Solution  method  for  the  EIGR  entry 

B.O. 

Char 

Lamination  option  for  PCOMPi  entries 

ACM? 

Char 

Component  type  for  airfoil  and  CAER06 
entries 

BCKP 

Char 

Component  type  for  BODY  and  PAER08 
entries 

BTYP 

Char 

CONV 

Char 

Conversion  factor  quantity  type  for  the 
CONVERT  entry 

CTY? 

|  Char 

Upper  or  Lower  bound  constraint  check 
for  DCONXXX,  entries 

FMETH 

mmm 

map-end  character  indicates  the  end  of  the  template,  and  so  must  occur  only  on  the  last  database  entity 
definition  line  for  the  final  set  of  the  template. 

S.2.3.2  SYSGEN  Output  for  Template  Definitions 


The  SYSGEN  outputs  consist  of  an  unstructured  entity  called  SYSTMPLT  which  contains  the 
templates  and  a  relation  called  TMPPOINT  which  allows  efficient  access  to  particular  templates.  The 
systmplt  entity  contains  one  RECORD  for  each  bulk  data  template  in  the  order  it  appears  in  the  input 
template  definition  file.  Therefore,  the  records  are  of  variable  length  with  the  longest  RECORD  contain¬ 
ing  80  characters  for  each  of  maxset  template  sets  of  nlptmp  lines.  The  TMPPOINT  relation  has  two 
attributes:  card  and  RECORD.  CARD  is  an  eight  character  string  attribute  containing  the  name  of  the  bulk 
data  entry  and  record  is  the  number  where  the  template  is  stored  in  SYSTMPLT. 

3.2.4.  Relational  Schema  Definition 

Each  relational  database  entity  requires  a  SCHEMA  that  defines  its  data  attributes.  A  sequential 
file,  containing  character  data,  is  used  to  define  these  schemata.  For  each  relation  there  is  a  list  of  the 
attribute  names,  their  types,  and,  if  they  are  arrays  or  character  data,  their  length.  The  details  of  this  file 
are  described  below: 

3.2.4.1  The  File  Format 


The  schema  definition  file  is  organized  as  shown  below: 


REL(l)  ENTRY 
REL (2 )  ENTRY 

REL(NREL)  ENTRY 


Each  RELATION  entry  has  the  following  form  of  free  field  input.  Each  input  may  appear  anywhere 
on  the  line  separated  by  one  or  more  blanks  except  "RELATION"  and  "end". 

ATTRNAME  ATTRTYPE  ATTRLEN 
END 


where 


relation  is  the  keyword  "relation"  which  signifies  that  a  new  relation  schema 
follows.  Must  begin  in  column  1. 

relnam  is  the  name  of  the  RELATION;  it  may  be  one  to  eight  characters  beginning 

with  a  letter. 

attrname  is  the  name  of  the  attribute;  it  may  be  one  to  eight  characters  beginning 

with  a  letter. 

attrtype  is  the  type  of  the  attribute  selected  from: 

’INT’  Integer 

’xi NT’  Keyed  Integer 
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’AIN'T’  Array  of  Integers 

’RSP’  Real,  single  precision 

’AKSP’  Array  of  real,  single  precision 

’rdp’  Real,  double  precision 

’STR’  Character  string 

’kstr’  Keyed  character  string 

attrlen  is  the  optional  length  of  the  Attribute.  If  it  is  of  type  aint,  arsp,  ardp, 

STR,  or  RSTR,  the  length  is  not  optional.  For  other  types,  it  should  be  zero  or 
not  present. 

END  is  the  keyword  "END"  which  signifies  the  LND  of  the  RELATION  schema. 

3.2A2  SYSGEN  Output  for  Relations 

The  data  defined  by  the  RELATION  schema  file  are  processed  and  the  results  are  stored  in  twe 
entities  op  the  system  database.  The  first  is  a  RELATION  called  RELINDBX.  This  entity  has  an  attribute 
reltnamb  containing  the  name  of  the  relation  and  an  attribute  schmpntr  which  is  an  integer  pointer 
to  an  unstructured  entity  called  relscheh.  The  relschbm  entity  contains  a  list  of  attribute  names,  types 
and  lengths  for  each  relation.  Each  relation  has  one  tuple  in  the  relindbx  relation  and  one 
RECORD  in  the  relschem  entity.  Each  relschem  record  consists  of  a  four  word  entry  for  each  attribute: 
two  Hollerith  words  containing  the  attribute  name,  one  hoilerith  word  containing  the  attribute  type  and 
an  integer  word  containing  the  attribute  length. 

3.2.5.  Error  Message  Text  Definition 

The  text  of  ASTROS  run  time  messages  is  stored  and  maintained  on  a  sequential  file  which  is 
used  during  system  generation  to  create  SYSDB  entities  for  use  by  the  ASTROS  message  writer  utility 
module.  There  are  two  reasons  for  .maintaining  the  message  text  on  an  external  file  (and  on  SYSDB). 
First,  the  storage  of  message  text  within  the  functional  modules  would  use  a  large  amount  of  memory 
during  execution.  Second,  storing  the  messages  together  in  an  external,  file  allows  for  easier  maintenance 
and  aids  in  avoiding  needless  duplication  in  message  texts.  The  messages  stored  on  SYSDB  from  this  file 
are  used  by  the  ASTROS  utility  utmwrt  to  build  error  messages  during  execution. 

3.2.5.1  The  File  Format 

The  message  text  file  is  organized  as  follo  ws: 

♦MODULE  1  {<header>} 
messages 

♦MODULE  2  {<header>} 
messages 

♦MODULE  3  {<header>) 


♦MODULE  <n>  {<header>} 
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The  header  is  an  optional  label  of  any  length  or  content  up  to  120  characters  that  typically  would 
describe  the  relationship  among  the  messages  for  the  specified  module.  In  this  way,  messages  that  are 
logically  related  (for  example,  all  error  conditions  from  the  ifp  module)  can  be  grouped  together  for 
simplified  maintenance.  The  module  number  <n>  is  a  unique  integer  identifying  the  base  module  number 
for  the  group  of  error  messages.  It  need  not  be  consecutive,  which  allows  for  randomly  numbered  mod¬ 
ules. 


The  format  of  the  message  text  is  as  follows: 

'message  text  $  more  text  $  . _  I 

the  string  is  enclosed  in  a  single  quotation  marks  because  the  message  will  be  used  as  a  character  string 
in  a  FORTRAN  write  statement.  The  $  (dollar  sign)  is  used  by  the  tjtmwrt  utility  to  place  character 
arguments  into  the  string.  For  example, 

'$  ELEMENT  $  IS  ATTACHED  TO  SCALAR  POINT  $/ _ _ 


would  appear  for  CTRMEM  element  100  attached  to  scalar  point  1001: 

j  CTRMEM  ELEMENT  100  IS  ATTACHED  TO  SCALAR  POINT  1001. 


If  the  user  wishes  the  message  to  carry  over  to  the  next  output  record,  the  FORTRAN  format  RECORD 
terminator  (/)  can  be  used  outside  the  quotation  marks  to  cause  a  record  advance.  For  example: 

|  'THIS  IS  ON  LINE  1'/'  THIS  IS ' ON  LINE  2.'  I 

Currently  there  is  an  implementation  limit  of  128  characters  for  the  length  of  the  message  text  after 
including  the  arguments.  Further  details  are  given  in  the  documentation  for  the  OTMWRT  utility  module. 

ZM. 5.2  SYSGEN  Output  for  Error  Message  Text 

The  data  in  the  message  file  are  used  to  create  two  system  database  entities.  The  first  is  an 
indexed  unstructured  entity  called  EREMSG.  This  entity  contains  one  line  of  the  message  text  file  in  each 
record.  The  second  is  an  unstructured  entity  called  ERMSQPNT  which  has  one  record.  That  record  has  two 
words  for  each  module  defined  in  the  message  file.  Those  words  are  the  module  number  <n>  and  the 
record  number  of  the  ERRMSG  RECORD  containing  the  module  header.  These  are  used  by  the  otmwrt  to 
position  to  the  proper  message  text  when  called. 
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3.3.  GENERATION  OF  THE  ASTROS  SYSTEM 


Following  the  execution  of  the  SYSGEN  program  the  system  installation  proceeds  to  the  genera¬ 
tion  of  the  ASTROS  executable  image.  As  indicated  in  Section  3.2,  the  SYSGEN  program  writes  a 
FORTRAN  program  called  xqdriv  which  must  be  linked  with  the  remainder  of  the  source  code  to  form 
the  ASTROS  system.  It  is  this  FORTRAN  program  which  provides  the  flexible  interface  hetween  the 
ASTROS  executive  and  the  remainder  of  the  ASTROS  modules,  to  generate  the  ASTROS  system,  there¬ 
fore,  it  is  essential  to  execute  the  SYSGEN  program  as  a  first  step. 

The  SYSGEN  execution  is  only  required  once  to  generate  the  standard  version  of  ASTROS.  This 
is  the  version  that  is  defined  by  the  delivered  set  of  SYSGEN  input  files  described  in  Section  3.2.  If, 
however,  the  users  of  the  system  at  a  particular  installation  desire  to  insert  additional  modules,  the 
SYSGEN  program  must  be  re-executed  to  recreate  the  XQDRIV  submodule.  The  users  may  also  want  to 
modify  other  SYSGEN  inputs  to  update  the  system  database  to  include  additional  input  entries  or  new 
relational  schema.  These  changes  also  require  the  re-execution  of  the  SYSGEN  program  (to  update  the 
system  database)  but  do  not  require  an  update  of  the  ASTROS  system.  For  most  purposes,  only  the 
module  definition  file  described  in  Section  3.2.1  requires  that  the  ASTROS  executable  image  be  recreated. 
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4.  EXECUTIVE  SYSTEM 


The  ASTROS  executive  system,  as  described  in  Section  3  of  the  Theoretical  Manual,  may  be 
viewed  as  a  stylized  computer  with  four  components:  a  control  unit,  a  high  level  memory,  an  execution 
monitor  and  an  Input/Output  subsystem.  The  first  three  components  comprise  the  executive  system 
modules  while  the  I/O  subsystem  is  embodied  in  the  database.  The  ASTROS  modules  that  comprise  the 
executive  system  perform  tasks  to  establish  the  ASTROS/host  interface,  initiate  the  execution  and,  upon 
completion  of  the  MAPOL  instructions,  terminate  the  execution.  These  modules  also  compile  the  MAPOL 
sequence,  if  necessary,  and  initiate  the  execution  monitor  that  interprets  the  MAPOL  instructions  guid¬ 
ing  the  execution.  This  section  documents  the  modules  of  the  ASTROS  executive  system. 

The  typical  user  of  ASTROS  need  not  be  familiar  with  the  executive  system  modules  since  their 
execution  path  does  not  have  the  flexibility  that  is  available  for  the  engineering  modules.  The  executive 
modules,  however,  are  important  from  the  viewpoint  of  the  system  manager  and  the  program  developer 
for  several  reasons.  First,  problems  with  the  machine  dependent  library  on  a  new  host  system  often  show 
up  during  the  executive  modules’  initialization  tasks.  The  executive  system  modules  are  also  important  in 
understanding  the  treatment  of  the  user’s  input  data  stream.  To  isolate  the  use  of  external  files  to  the 
executive  system,  for  example,  the  PRBPAS  executive  module  reads  the  input  data  stream  and  loads  those 
portions  that  deal  with  the  MAPOL,  Solution  Control  and  Bulk  Data  packets  to  the  database.  The  system 
manager,  therefore,  may  find  it  useful  to  study  the  nature  of  the  executive  modules  and  their  interrela¬ 
tionships  to  better  understand  the  implementation  of  the  ASTROS  architecture. 
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Executive  System  Module:  ASTROS 
Entry  Point:  ASTROS 


PURPOSE: 

ASTROS  is  the  main  entry  point  for  the  ASTROS  procedure.  It  controls  the  execution  path  through  the 
executive  system  modules. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

None 

Method: 

The  ASTROS  routine  first  sets  a  flag  to  tell  the  executive  modules  that  subsequent  calls  are  associated 
with  the  ASTROS  procedure  rather  than  with  the  SYSGEN  program.  This  flag  is  required  since  the 
compiler  and  other  executive  routines  are  shared  between  the  two  programs  and  require  sightly  different 
execution  paths.  The  machine  dependent  initialization  routine,  XXINIT,  is  then  called  to  perform  the 
initialization  tasks  required  on  the  current  host  system.  The  initialization  is  completed  by  zeroing  the 
execution  monitor’s  stack  length,  calling  the  machine  independent  initialization  routine,  XQINIT, 
labeling  the  output  listing  and  the  starting  the  timing  summary. 

The  PRBPAS  module  is  then  called  to  read  the  user’s  input  data  stream.  On  return  from  prbpas,  the 
MAPOL  compiler  i6  called  if  a  MAPOL  compilation  is  required.  Finally,  the  execution  monitor,  XQTMGN, 
is  called  to  interpret  the  ASTROS  machine  instructions  representing  the  compiled  MAPOL  sequence. 
All  subsequent  activities  in  the  ASTROS  execution  are  controlled  by  this  module  until  all  the  MAPOL 
instructions  have  been  completed.  Upon  return  from  XQTMON,  the  main  driver  terminates  the  execution 
by  writing  the  closing  label,  calling  the  XQKNDS  module  to  close  the  database,  dumping  the  timing 
summary  and  performing  any  other  closing  tasks. 

The  engineering  modules  (addressed  by  the  execution  monitor)  may  also  terminate  the  execution  of  the 
system.  In  these  cases,  the  geuez  al  application  utility  module,  UTBXIT,  is  used  since  this  routine  assumes 
that  an  error  exit  bog  occurred.  UTE2IT,  however,  also  calls  the  XQENDS  executive  module  to  assure 
clean  termination  of  all  executions. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Executive  System  Module: 
Entry  Point;  XQINIT 
PURPOSE: 


XQINIT 


lb  perform  machine  independent  system  initialization  tasks. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  XQIHIT 

Method: 

This  routine  completes  the  page  titling  information  on  the  TITLE  line  used  by  the  OTPAGE  utility.  The 
ASTROS  version  number  is  placed  in  TITLE  (which  is  in  the  /OOTPOT2/  common  block)  in  characters 
88  through  107.  The  current  date  is  obtained  using  xxdate  and  placed  in  characters  109  to  117.  The 
page  number  label  is  then  placed  in  characters  120  to  121.  Thus,  the  page  number  itself  is  left  to  fit  in 
characters  123  to  128. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Executive  System  Module:  PREPAS 

Entry  Point:  PREPAS 

PURPOSE: 


lb  perform  the  first  pass  through  the  user’s  input  data  stream,  to  initialize  the  open  core  memory 
manager  and  to  attach  the  scratch  and  system  databases. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  PREPAS  (  MAPFLG,  SOLFLG,  BLKFLG  ) 

MAPFLG  Integer  flag  denoting  the  presence  or  absence  of  a  MAPOL  packet  in  the 

input  data  stream  (Output) 

=  0  if  no  MAPOL  packet 

m  1  if  a  MAPOL  packet  exists  in  the  input  stream 

SOLFLG  Integer  flag  defined  like  MAPFLG  denoting  the  presence  or  absence  of  a  So¬ 

lution  Control  packet  in  the  input  data  stream  (Output) 

BLKFLG  Integer  flag  defined  like  MAPFLG  denoting  the  presence  or  absence  of  a 

Bulk  Data  packet  in  the  input  data  stream  (Output) 

Method: 

This  routine  performs  the  first  pass  over  the  user’s  input  data  stream,  performs  actions  based  on  the 
ASSIGN  DATABASE,  DEBUG  and  MAPOL  EDIT  command  inputs  and  prepares  MAPOL,  solution  control 
and  bulk  data  inputs  for  access  by  the  appropriate  modules.  The  order  of  operations  is  crucial  and  can 
be  summarized  as  follows: 

1.  The  debug  packet  must  be  processed  first  since  the  debug  flags  can  affect  the  memory  management 
system. 

2.  Immediately  following  the  debug  packet,  the  memory  manager  must  be  initialized,  and  the  scratch 
(run-time)  database  (based  on  the  ASSIGN  DATABASE  entry)  and  the  system  database  must  be 
attached,  in  that  order.  The  order  is  dictated  by  the  requirement  that  the  memory  manager  be 
available  for  the  DBINIT  calls  and  the  scratch  database  must  be  allocated  before  the  system 
database.  The  system  database  must  be  allocated  in  order  to  process  the  MAPOL  packet  (which  may 
apply  EDIT  operations  to  the  standard  MAPOL  sequence  stored  on  the  system  database). 

Once  the  assign  database  and  debug  packets  are  processed,  the  remaining  packets  could  be  ordered 
in  any  fashion,  but  a  fixed  sequence  of  MAPOL,  solution  control  and  bulk  data  packets  has  been  imposed. 

The  procedure  used  in  PREPAS  is  to  read  the  input  stream  one  80-character  record  at  a  time.  The  first 
nonblank  records  must  be  the  ASSIGN  database  entry.  The  corresponding  records  are  set  aside  in 
ASNCRD  for  use  after  the  debug  packet  is  processed.  After  the  ASSIGN  DATABASE  entry  has  been 
encountered,  each  input  record  is  read  and  searched  to  see  if  one  of  the  input  stream  keywords  appears 
in  the  first  eight  characters  following  the  first  nonblank  character.  The  keywords  are: 

1.  debug  denoting  the  start  of  the  debug  packet 

2.  MAPOL  denoting  the  start  of  the  MAPOL  packet  containing  a  complete  new  MAPOL  sequence 
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3.  edit  denoting  the  start  of  the  MAPOL  packet  containing  edit  commands  to  be  applied  to  the 
standard  sequence 

4.  solution  denoting  the  start  of  the  solution  control  packet 

5.  "begin_"  denoting  the  start  of  the  bulk  data  packet.  Note  the  trailing  blank  after  BEGIN  and  the 
absence  of  the  optional  BULK  keyword. 

6.  enddata  denoting  the  end  of  the  bulk  data  packet 

7.  include  naming  the  secondary  file  from  which  to  read  the  input 

Note  that  all  the  keywords  except  enddata  and  INCLUDE  mark  the  beginning  of  a  new  packet.  The 

INCLUDE  keyword  does  not  change-  the  current  packet  and  ENDDATA  marks  the  end  of  the  valid  input. 

If  the  current  record  is  one  of  the  keyword  records,  flags  are  set  to  indicate  that  a  new  packet  has  been 

initiated  or,  for  include,  the  Liclude  file  is  opened  and  processing  continues  with  the  new  input  file 

until  it  is  exhausted.  Records  that  are  not  keyword  records  are  processed  as  follows: 

1.  DEBUG  packet  records  are  sent  to  the  CRKBUG  utility  to  interpret  the  debug  commands  and  set  the 
executive  system  debug  command  flags  in  the  /EXEC 02  /  common  and  set  the  other  debug  command 
flags  by  utsflg  to  activate  run  time  debugs. 

2.  MAPOL  packet  records  representing  a  .replacement  MAPOL  sequence  are  written  to  the  unstruc¬ 
tured  entity  &MAPLPKT  for  processing  in  the  MAPOL  module. 

3.  MAPOL  packet  records  representing  an  EDIT  of  the  standard  sequence  are  passed  to  the  MAPEDT 
subroutine  to  be  interpreted.  The  resultant  MAPOL  sequence  is  written  to  the  unstructured  entity 
&MAPLPKT  for  processing  in  the  MAPOL  module. 

4.  solution  packet  records  are  written  to  the  unstructured  entity  &SOLNPKT  for  processing  in  the 
solution  module. 

5.  Bulk  Data  packet  records  are  written  to  the  unstructured  entity  6BKDTPKT  for  processing  in  the  IFP 
module. 

Design  Requirements: 

None 

Error  Conditions: 

1.  Input  stream  does  not  begin  with  an  ASSIGN  database  entry. 

2.  An  input  stream  keyword  appears  out  of  order. 

3.  An  enddata  statement  appears  outside  the  bulk  data  packet. 

4.  No  filename  was  found  on  an  include  statement. 

5.  include  file  cannot  be  opened. 

6.  Input  record  lies  outside  any  input  packet  (typically  following  an  ENDDATA) 

7.  FORTRAN  read  error  on  the  primary  input  stream  or  included  file. 

8.  An  INCLUDE  statement  appearing  in  a  included  file. 
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Executive  System  Module:  MMINIT 

Entry  Point:  MMINIT 

PURPOSE: 


lb  initialize  the  memory  manager. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MMINIT  (  SIZE  ) 

SIZE  The  number  of  single  precision  words  in  open  core  (Integer,  Input) 

Method: 

This  routine  establishes  the  initial  block  headers  for  open  core  memory.  A  block  header  is  written 
representing  one  free  block  of  SIZE  words  less  those  required  for  the  block  header.  The  block  header  is 
either  six  or  eight  words  depending  on  whether  the  MEMORY  debug  has  been  selected  by  the  user  in  the 
input  stream.  The  size  must  correspond  to  the  actual  declared  length  of  the  open-core  common  block 
/MEMORY/. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Executive  System  Module:  DBINIT 


DBINIT 


PURPOSE: 


lb  initialize  the  processing  for  a  database. 
MAPOT.  Calling  Sequence: 


plication  Catling  Sequence: 

CALL  DBINIT  (  DBNAKE,  PASSWD,  STAT,  RW,  USRPRM  ) 


DBNAMS 


PASSWD 


USRPRM 


The  database  name  (Character,  Input) 

The  database  password  (Character,  Input) 

The  database  status  (Character,  Input) 

One  of  OLD,  NEW,  SAVE,  PERM  or  TEMP 

Read/Write  status  (Character,  Input) 

One  of  RO  or  R/W 

Installation  dependent  user  parameters  (Character,  Input) 


Method: 


This  routine  opens  the  named  database  for  access.  It  performs  any  machine  and  installation  dependent 
processing  by  accessing  the  database  machine  dependent  library  routines  DBMDCX  and  DBMDIX.  All  the 
in-core  buffers  required  for  subsequent  database  access  are  allocated  using  the  database  memory 
management  routines. 

Design  Requirements: 

1.  The  first  call  to  DBINIT  must  define  the  run-time  or  scratch  database.  Any  other  databases  may 
then  be  initialized. 

Error  Conditions: 

1.  Any  error  conditions  on  the  file  operations  occuring  in  DBINIT  will  terminate  the  execution. 


3oint:  DBCINI 


PURPOSE: 

Tb  initialize  the  processing  for  a  database  and  return  a  status  code  rather  than  terminate  on  error. 
MAPOL  Calling  Sequence: 


ilication  i 


sequence: 


CALL  DBCINI  (  DBNAMS,  PASSWD,  STAT,  RW,  USRPRM,  ISTAT  ) 


DBNAKE 


The  database  name  (Character,  Input) 
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PASSWD 

The  database  password  (Character,  Input) 

STAT 

The  database  status  (Character,  Input) 

One  of  old,  new,  save,  perm  or  temp 

RW 

Read/Write  status  (Character,  Input) 

One  of  RO  or  R/w 

USRPRK 

Installation  dependent  user  parameters  (Character,  Input) 

ISTAT 

Return  status 

1  -  Duplicate  database  name 

2  -  Tbo  many  databases  open 

3  -  Bad  EW  parameter 

4  -  Index  file  block  size  too  small 

f>  -  Bad  data  in  file  found  on  old  open 

6  -  Password  check  failure  on  old  open 

7  -  Old  formatted  database  not  supported 

8  -  Read  only  open  on  new  database  illegal 

9  -  Bad  STAT  parameter 

100  -  Values  are  machine  dependent  -  see  dbmdix 

Method: 

This  routine  opens  the  named  database  for  access.  It  performs  any  machine  and  installation  dependent 
processing  by  accessing  the  database  machine  dependent  library  routines  DBMDCX  and  DBMDIX.  All  the 
in-core  buffers  required  for  subsequent  database  access  are  allocated  using  the  database  memory 
management  routines. 

Design  Requirements: 

1.  The  first  call  to  dbinit  must  define  the  r  n-time  or  scratch  database.  Any  other  databases  may 
then  be  initialized. 

Error  Conditions: 

1.  Any  error  conditions  on  the  file  operations  occuring  in  DBCXNX  will  be  flagged  using  the  ISTAT 
parameter  and  control  returned  to  the  calling  routine. 
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Executive  System  Module:  MAPOL 
Entry  Point:  MAPOL 


PURPOSE: 

lb  compile  a  MAPOL  program. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MAPOL 

Method: 

The  input  MAPOL  program  or  a  MAPOL  program  representing  a  modified  standard  sequence  is  read 
from  the  &MAPLPKT  unstructured  entity  and  compiled.  The  resultant  machine  code  instructions  and 
memory  map  are  written  to  the  MCODB  and  MEMORY  entities  for  use  by  XQTMON  in  executing  the  MAPOL 
program. 

Design  Requirements: 

None 

Error  Conditions: 

1.  MAPOL  syntax  errors 

2.  Illegal  argument  types  used  in  MAPOL  module  calls 
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Executive  System  Module:  XQTMON 

Entry  Point:  XQTMON 

PURPOSE: 


lb  execute  a  set  of  ASTROS  machine  instructions  representing  a  MAPOL  program. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  XQTMON 
Method: 

If  no  MAPOL  packet  was  in  the  input  stream,  XQTMON  copies  the  standard  sequence  machine  instruc¬ 
tions  and  memory  map  from  the  system  database  into  the  MCODB  and  MEMORY  entities.  If  a  MAPOL 
compilation  took  place,  the  current  sequence's  data  are  already  in  MCOras  and  MEMORY.  Beginning  with 
the  first  instruction,  which  is  passed  to  XQTMON  from  the  MAPOL  compiler  or  retrieved  from  the  system 
database,  ihe  machine  instructions  are  executed  by  this  module. 

Most  instructions  are  processed  directly  by  the  XQTMON  module;  for  example,  stack  operations,  entity 
creations  and  scalar  arithmetic  operations.  If  the  instruction  is  a  module  call,  however,  the  XQDRXV 
executive  subroutine,  previously  written  by  the  SYSGEN  program,  is  called  to  access  the  MAPOL 
module  to  which  the  machine  instruction  refers. 

Design  Requirements: 

None 

Error  Conditions: 

MAPOL  run  time  errors 


80 


Executive  System  Module:  XQENDS 

Entry  Point:  XQENDS 

PURPOSE: 


Tb  cleanly  terminate  the  ASTROS  execution. 

MAPGL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  XQENDS 

Method: 

The  executive  module’s  database  entities  that  remain  open  throughout  the  ASTROS  execution  are  closed 
and  the  dbtkrm  executive  module  is  called  to  close  the  database(s). 

Design  ReQuirements: 

None 

Error  Conditions: 

None 
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Executive  System  Module:  DBTERM 
Entry  Point:  DBTERM 


PURPOSE: 

Tb  terminate  processing  of  all  open  database. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBTERM  (  DBNAJG5  ) 

dbname  Database  name  or  blank  (Character,  Input) 

Method: 

The  database  entity  name  table  (ENT)  is  searched  and  all  open  entities  corresponding  to  DBNAME  are 
closed  and  the  ENT  deleted.  If  DBNAME  is  blank,  all  open  entities  on  all  databases  are  closed  but  the  ENTs 
are  not  deleted.  If  all  databases  are  to  be  closed,  the  database  name  table  (dbnt)  is  searched  and  all 
in-core  buffers  are  fined.  The  first  record  of  each  database  is  updated  to  indicate  that  it  was  properly 
closed  and  any  system  dependent  termination  is  performed.  If  a  particular  database  is  to  be  closed,  these 
operations  are  done  only  for  the  named  database.  Finally,  if  all  databases  are  closed,  the  ENT,  DBNT  and 
the  name  substitution  table  (nst)  are  released  at  the  close  of  the  dbterm. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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5.  ENGINEERING  APPLICATION  MODULES 


The  modules  documented  in  this  section  fall  under  the  category  of  engineering  application  mod¬ 
ules.  These  modules  constitute  the  majority  of  the  ASTROS  software  and  and  do  the  tasks  necessary  to 
perform  the  analyses  supported  by  the  ASTROS  system.  Unsurprisingly,  the  difference  between  an 
"engineering  application"  module  and  other  modules  in  the  ASTROS  system  is  not  always  clear.  The  most 
useful  definition  may  be  that  an  engineering  application  module  is  one  that  does  not  fall  into  any  other 
category.  They  do,  however,  share  some  common  attributes  that  can  be  used  to  help  distinguish  them 
from  other  modules.  First,  an  engineering  application  module  has  no  application  calling  sequence:  it  is 
only  accessible  through  the  executive  system.  A  related  attribute  is  that  no  engineering  module  may  be 
called  by  another  module,  v/hereas  utility  modules  may  be  called  by  other  modules  or  by  the  executive 
system.  Finally,  an  engineering  application  module  is  one  that  establishes  an  open  core  base  address  by 
calling  the  mmbase  and/or  mmbasc  utilities  and  uses  that  one  base  address  throughout  its  execution. 

The  following  subsections  document  each  of  the  engineering  application  modules  that  comprise 
the  ASTROS  system.  Each  module  is  documented  using  the  standard  format  shown  in  the  introduction, 
but  some  additional  comments  are  necessary.  First,  the  MAPOL  language  allows  the  use  of  optional 
arguments  in  the  calling  sequences.  This  feature  has  been  used  in  many  modules  to  provide  optional 
print  selections  or  to  allow  the  module  to  be  used  in  slightly  different  ways.  This  is  particularly  true  for 
the  matrix  reduction  "modules"  (©reduce,  fpeduce  and  HECOVA)  which  may  almost  be  considered  utili¬ 
ties.  When  the  argument  in  the  MAPOL  calling  sequence  is  optional,  it  is  so  indicated  in  the  calling  list. 
The  METHOD  section  then  describes  the  alternative  operations  that  take  place  depending  on  the  pres¬ 
ence  of  the  optional  argument. 

A  second  point  to  emphasize  is  the  general  nature  of  the  METHOD  sections  for  the  engineering 
module  documentation.  In  no  way  does  this  documentation  attempt  to  lead  the  leader  through  the  code 
segments  of  the  module.  Instead,  a  general  descripton  of  the  algorithm  is  given  which,  in  combination 
with  the  in-line  comments,  should  give  the  programmer  an  adequate  understanding  of  the  module.  The 
system  programmer  wanting  to  make  extensive  software  modifications  to  existing  modules  will  still  need 
to  study  the  actual  code  segments  in  some  detail.  The  level  of  detail  in  the  engineering  module  documen¬ 
tation  is  considered  more  appropriate  for  the  ASTROS  analyst/designer  who  wants  to  understand  howr 
ASTROS  uses  the  existing  pool  of  engineering  modules  and  to  know  the  "initial  state"  that  the  module 
expects  to  exist  when  it  is  called.  The  analyst  may  then  make  "nonstandard"  use  of  the  module  to  perform 
alternative  analyses.  These,  therefore,  are  the  data  emphasized  in  the  module  documentation  that  fol¬ 
lows. 
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Engineering  Application  Module:  ABOUND 
Entry  Point:  ABOUND 


Purpose: 

lb  generate  flags  for  the  current  -  oundary  condition  that  indicate  which  constraint  types  are  active. 
These  are  then  returned  to  the  executive  sequence  to  direct  the  execution  of  the  required  sensitivity 
analyses. 


MAPOL  Calling  Sequence: 

CALL  ABOUND  {  NITER,  BC,  CONST,  ACTBOUND,  NAUS,  NAC3D,  [PQAS] ,  PUA3,  ACTAERO, 
ACTDYN,  ACTFLUT,  NMPC,  NSPC,  NOMTT,  NRS2T,  NQJR,  rSETtBC)  ); 


NITER 

BC 

CONST 

ACTBOUND 


NAUS 

NACSD 

[PSAS] 

PCAS 


ACTAERO 


ACTDTN 

ACTFLUT 

NMPC 

NSPC 

NOWIT 

NRSKT 

NODR 

USET (BC) 


Design  iteration  number.  (Integer,  Input) 

Boundary  condition  identification  number.  (Integer,  Input) 

Relation  of  constraint  values.  (Character,  Input) 

Flag  denoting  if  the  boundary  condition  is  active.  (Integer,  Output) 

*  1  if  active 

=  0  if  inactive 

Number  of  active  STATICS  displacement  vectors.  (Integer,  Output) 

Number  of  active  STATICS  stress  and/or  displacement  constraints. 
(Integer,  Output) 

Partition  vector  for  active  STATICS  displacement  vectors.  (Output) 

Unstructured  entity  which  contains  the  unique  STATICS  subcase  num¬ 
bers  for  the  displacement  dependent  STATICS  constraints  that  are  active 
for  the  boundary  condition.  Only  constraints  for  the  current  boundary  con¬ 
dition  are  included  in  the  list.  (Output) 

Flag  denoting  the  presence  of  active  aeroalftfic  effectiveness  constraints. 
(Integer,  Output) 

*  I  if  any  effectiveness  constraints  are  active 

*  o  if  none  are  active 

Number  of  active  frequency  constraints.  (Integer,  Output) 

Number  of  active  flutter  constraints  (Integer,  Output) 

Number  ofMPC  degrees  of  freedom.  (Integer,  Output) 

Number  of  3PC  degrees  of  freedom.  (Integer,  Output) 

Number  of  omitted  DOF.  (Integer,  Output) 

Number  of  support  DOF.  (Integer,  Output) 

Denotes  dynamic  reduction  in  this  boundary  condition.  (Integer,  Output) 

=  0  No  SDR 
=  -1  OCR  is  used 

The  unstructured  entity  defining  structural  sets  for  each  degree  of  free¬ 
dom.  (Character,  Input) 
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Application  Calling  Sequence: 

None 

Method: 

The  module  first  reads  the  const  relation  for  active  constraints  associated  with  the  boundary  condition. 
If  any  entries  are  found,  the  ACTBOPND  flag  is  set  to  on.  If  not.  control  is  returned  to  the  executive. 

The  case  relation  is  then  read  for  ail  sul  cases  associated  with  the  boundary  condition.  The  number  of 
statics  subcases  is  counted  in  preparation  for  determining  the  partitioning  vector  of  active  subcases 
and  the  counts  of  right-hand-sides  and  constraints  that  will  determine  if  the  gradient  or  virtual  load 
method  will  be  used  in  sensitivity  analysis.  SAERO  disciplines  cannot  use  the  virtual  load  method  and 
are  therefore  not  treated  in  this  manner. 

Then  the  trSET  and  case  entities  are  searched  to  set  the  boundary  condition  flag3  that  are  output  to 
control  the  reduction  processes  during  the  sensitivity  phase.  Then  the  work  of  the  module  begins. 

The  active  subcases  and  constraint  types  are  determined  for  each  of  the  entries  in  const  that  were  read. 
During  tbs  pass  through  the  active  constrai  nt  set,  the  partitioning  vector  for  the  STATICS  displacement 
matrix  is  built  (of  the  number  of  right-hand-sides  columns,  only  the  NAUS  columns  will  be  active).  For 
statics  constraints  that  are  dependent  on  the  displacement  vector  derivatives,  the  active  subcase  is 
identified  and  the  partitioning  vector,  PGA s,  and  the  set  of  subcase  ids  that  are  active,  pcas,  are  loaded. 

Then  a  summary  of  all  the  active  constraints  for  the  boundary  condition  is  echoed  to  the  output  file. 

Design  Requirements: 

1.  This  module  must  follow  the  complete  analysis  phase  for  all  the  boundary  conditions  arid  is  the  first 
module  called  within  the  sensitivity  boundary  condition  loop. 

Error  Conditions: 

None 
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Engineering  Application  Module:  ACTCON 
Entry  Point:  ACTCON 


Purpo3e: 

Tb  determine  whether  the  design  task  has  converged.  If  the  optimization  has  not  converged,  this  module 
selects  which  constraints  are  to  be  included  in  the  current  redesign.  On  print  request,  this  routine 
computes  and  prints  the  values  of  the  local  design  variables. 

MAPOL  Calling  Sequence: 

CALL  ACTCOtt  {  NITER,  MAXITBR,  NRFAC,  NDV,  GLBDES,  LOCLVAR,  [PTRAN3]  ,  BPS , 
APPCNVRG,  GLBCNVRG,  CTL,  GTIHIN ,  COK3T ,  fAMAT]  ,  DESHIST , 

FFLAG,  OLOCALDV  ) ; 


NITER 

MAXZTZR 

NRFAC 

KDV 

GLBDES 

LOCLVAR 

IPTRANS] 

EPS 

APPCNVRG 


GLECNVRG 

CTL 

CTX£?IN 

CONST 

[AKAT] 

DESHIST 

PFLAG 

OLOCALDV 


The  current  iteration  number.  (Integer,  Input) 

The  maximum  number  of  allowable  iterations.  (Integer,  Input) 

Determines  the  minimum  number  of  retained  constraints  equal  to 
NRFAC*NDV.  (Real,  Input) 

The  number  of  global  design  variables.  (Integer,  Input) 

Relation  of  global  design  variables.  (Character,  Input) 

Relation  containing  the  relationship  between  local  variables  and  global 
variables  in  the  design  problem.  (Character,  Input) 

The  design  variable  linking  matrix.  (Character,  Input) 

A  second  criteria  for  constraint  retention.  All  constraints  greater  than  or 
equal  to  EPS  will  be  retained.  (Real,  Input) 

The  approximate  problem  converge  flag  from  module  DESIGN  or  FSD 
(Logical,  Input) 

*  FALSE  if  not  converged 

*  TRUE  if  no  change  in  objective  function  value  and  design  variables 

Final  convergence  flag  (Logical,  Output) 

=  FALSE  if  not  converged 
«  true  if  global  converge  was  achieved 

Constraint  tolerance  for  active  constraints.  (Real,  Input) 

Constraint  tolerance  for  violated  constraints.  (Real,  Input) 

Relation  of  constraint  values.  (Character,  Input) 

The  matrix  entity  of  constraint  gradients.  (Output) 

Relation  of  design  iteration  information.  (Character,  Input) 

The  logical  flag  to  indicate  if  design  model  punching  is  requested  for  the 
current  iteration.  (Logical,  Input) 

Relation  to  store  the  output  local  design  variables  requested  in  solution 
control  (Character,  Input) 
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Application  Calling  Sequence: 

None 

Method: 

The  initial  action  of  the  ACTCOH  module  is  to  flush  the  [AMAT]  matrix  of  constraint  gradients  for  the 
sensitivity  analysis  that  is  to  follow.  This  erases  the  constraint  sensitivities  from  the  previous  design 
iteration  and  prepares  the  matrix  to  be  loaded  by  the  constraint  sensitivity  evaluation  modules. 
Following  this  bookkeeping  task,  the  ACTCON  module  begins  the  process  of  selecting  the  active 
constraints  for  the  next  redesign  cycle.  The  first  computation  of  the  number  of  retained  constraints  is 
done  using  the  value  nrfac*hdv.  This  represents  a  minimum  number  of  constraints  to  retain.  The 
vector  of  current  constraint  values  is  brought  into  core  and  sorted.  Then  the  EPS  value  and  initial  number 
of  retained  constraints  are  used  to  determine  the  cutoff  value  for  the  active  constraints.  This  cutoff  value, 
CM1N,  will  either  be  the  constraint  value  such  that  NREAC*HDV  constraints  are  retained,  the  constraint 
value  closest  to,  but  less  than,  EPS  or  the  minimum  constraint  value  if  there  are  fewer  than  NRPAC*HDV 
constraints.  During  this  phase  the  count  of  thickness  constraints  that  are  retained  even  though  they  do 
not  satisfy  the  HRFAC  and  EPS  retension  criteria  is  kept.  A  summary  is  printed  that  indicates  the  number 
of  constraints  kept  for  each  reason:  NRFAC,  EP3  and  DCONTHK. 

If  the  approximate  problem  convergence  flag,  APPCNVRG,  is  TRUE,  the  maximum  constraint  value  is 
tested  to  determine  if  global  convergence  has  been  achieved  based  on  CTL  and  CTUCTN.  The  OLSCHVRG 
flag  is  set  to  true  if  global  convergence  has  been  reached. 

The  next  task  of  the  ACTCOH  module  is  to  set  the  active  constraint  attribute  in  the  CONST  relation.  This 
is  done  by  retrieving  each  tuple  of  the  CONST  relation  and  comparing  the  constraint  value  against  the 
cutoff  value,  CMXN.  The  appropriate  constraints  are  then  marked  active  by  setting  the  ACTVFLAG 
attribute  to  unity.  Finally,  the  ACTCQN  module  prints  out  the  results  of  the  design  process  if  global 
convergence  or  the  maximum  number  of  iterations  has  been  reached.  This  includes  the  print  of  the 
design  iteration  history  and,  if  requested  by  Solution  Control,  the  summary  of  global  and  local  design 
variables. 

Design  Requirements: 

1.  ACTCOH  must  be  the  first  module  called  following  the  analysis  phase  of  the  optimization  segment  of 
the  standard  sequence.  That  is,  it  follows  all  the  analysis  boundary  conditions  but  precedes  the 
sensitivity  evaluations. 

Error  Conditions: 

1.  No  design  constraints  have  been  applied  in  the  optimization  problem. 
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Engineering  Application  Module:  AEROE  FFS 
Entry  Point:  AROSE  F 


Evaluates  aeroelastic  effectiveness  sensitivities. 


sequence: 


C&Uj  AEROEFF3  {  NITER,  BC ,  SUB,  SYM,  NDV,  CONST,  PCAE ,  [EFFSENS]  ,  [MSATJ  )  ; 


NITER 


CONST 


EFFSENS 


Current  iteration  number.  (Input,  Integer) 

Current  boundary  condition  number.  (Input,  Integer) 

Current  static  aeroelastic  subscript  number.  (Input,  Integer) 

Symmetry  flag  for  the  current  call.  Either  1  for  symmetric  or  -1  for  anti¬ 
symmetric.  (Input,  Integer) 

Number  of  global  design  variables.  (Input, Integer) 

Relation  of  design  constraints.  (Input) 

Unstructured  entity  containing  information  indicating  which  pseudodis¬ 
placements  (displacements  due  to  unit  configuration  parameters)  are  ac¬ 
tive  for  the  current  design  iteration.  (Input) 

The  matrix  of  dimensional  stability  derivative  sensitivities.  (Input) 

The  matrix  of  constraint  gradients.  (Output) 


Method: 


The  CASE  relation  is  read  first  to  retrieve  the  SUPPORT  set  for  the  current  boundary  condition.  The 
number  and  location  of  the  support  DOF  are  returned  from  the  utility  routine  S3FCHK.  Then  the  CONST 
relation  is  read  for  active  lift  effectiveness  (DCCNCXA),  aileron  effectiveness  (dcohals)  and  stability 
coefficient  constraints  (dconscf)  for  the  current  boundary  condition,  subscript  and  iteration. 

The  EFFSENS  matrix,  of  dimension  NSUP*NDV*NAUE  whene  NSUP  is  the  number  of  support  dofs  and 
NAT3E  is  the  number  of  active  pseudodisplacement  fields  of  the  set  computed  in  sabro  for  the  applied 
constraints. 


The  whole  EFFSENS  matrix  is  read  into  memory  and  then  the  loop  over  active  constraints  begins.  For 
each  active  constraint,  the  diepcol  attribute  of  the  const  relation  is  used  to  determine  which  column 
of  pseudodisplacements  is  associated  with  the  constraint.  The  pcaf  entity  is  then  used  to  determine 
which  column  of  the  reduced  set  of  active  pseudodisplacement  fields  is  the  proper  column.  Once  located, 
the  constraint  sensitivities  may  be  computed  from  the  dimensional  stability  coefficient  derivatives  and 
the  normalization  data  stored  in  the  const  relation  in  the  SAEKO  module.  The  constraint  derivatives 
are  computed  fromthe  following  relationships. 
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I  'ft  Effectiveness: 
Upper  Bound 


CLAREQ  >0.0 

DG/DX  =  SENS  ROW  /  (CLA  *  CLAREQ  ) 

RIGID 

CLAREQ  <0.0 

DG/DX  ~  -SENS  ROW  /  (CLA  *  CLAREQ  ) 

RIGID 

CLAREQ  =0.0 

DG/DX  =  SENS  ROW  /  CLA 

RIGID 


CLAREQ  >  0.0 

DG/DX  =  -SENS  ROW  /  (CLA  *  CLAREQ  ) 

RIGID 

CLAREQ  <0.0 

DG/DX  =  SENS  ROW  /  (CLA  *  CLAREQ  ) 

RIGID 

CLAREQ  =0.0 

DG/DX  =  -SENS  ROW  /  CLA 

RIGID 


where  CLArigid  is  stored  in  the  SENSERM1  attribute  of  CONST  and  CLAREQ  is  stored  in  the  SENSOR M2 
attribute  of  const 

Aileron  Effectiveness: 

Upper  Bound 


AEREQ  >0.0 

| 

DG/DX  = (-SENS  * 

CMXP  +  SENS  *  CMXA  )  / 

(AEREQ  * 

CMXP  **2)j 

I 

FLX  2  FLX 

FLX  ? 

AEREQ  <0.0 

DG/DX  =  (  SENS  * 

CMXP  -  SENS  *  CMXA  )  / 

(AEREQ  * 

CMXP  **2) 

I 

FLX  2  FLX 

FLX 

AEREQ  =0.0 

DG/DX  = (-SENS  * 

CMXP  +  SENS  •*  CMXA  )  / 

CMXP  **  2 

L_ _ 

1 

FLX  2  FLX 

FLX 

Lower  Bound 


AEREQ  >0.0 

DG/DX  =(  SENS  * 

CMXP  -  SENS  * 

CMXA  )  / 

(AEREQ  * 

- — - — j 

CMXP  **2)| 

1 

FLX  2 

FLX 

FLX  j 

AEREQ  <  0.0 

DG/DX  = (-SENS  * 

CMXP  +  SENS  * 

CMXA  |  / 

(AEREQ  * 

i 

CMXP  **2;j 

1 

FLX  2 

FLX 

FLX  | 

AEREQ  =0.0 

DG/DX  =•(  SENS  * 

CMXP  -  SENS  * 

CMXA  )  / 

CMXP  **  2 

j 

. _ 

1 

FLX  2 

FLX 

FLX 

where  CXMAflex  is  stored  in  the  smssmi  attribute  of  const  and  CMXPflex  is  stored  in  the 
SEHSPHH2  attribute  of  CONST  ar.d  2 ,  0*&E»EQ/  <57 . 3*REEB)  is  in  SENSfSE43 


Stability  Coefficient: 


Upper  Bound 


Lower  Bound 


where  REQ,  the  dimensional  required  value  is  stored  in  the  3EN3FRM1  attribute  of  const 

The  rows  of  EFFSEN3  associated  with  each  constraint  are  dependent  on  the  constraint  type  in  the 
following  way: 

( 1)  Lift  Effectiveness  constraints  always  use  the  plunge  DOF 

(2)  Aileron  Effectiveness  constraints  always  use  the  roll  DOF 

(3)  Stability  Coefficient  constraints  always  use  the  row  associated  with  the  constrained  axis.  The 
constrained  axis  number  (1,2,3, 4, 5,G)  is  stored  in  real  form  in  the  SKNSK&2  attribute  of  const. 

Design  Requirements: 

— ■WfcOKMJO*— fcowaoMO  11  jhObi  r>  m  »  m.  p 

None 

Error  Conditions: 

None 
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Engineering  Application  Module:  AEROSENS 


Entry  Point:  AROSNS 


Purpose: 

Tb  compute  the  sensitivities  of  the  rigid  body  accelerations  and  aerodynamic  performance  parameters 
(dcontrm)  for  active  steady  aeroelastic  subcases  associated  with  the  current  subscript. 

MAPOL  Calling  Sequence: 

CALL  AEROSENS  (  NITER,  BC,  MIND’JC,  SOB,  CONST,  SXM,  NDV,  BGPDT(BC)  ,  STABCF, 
[BGAA] ,  [LHSA (BC , 30B) ] ,  [RHSA  (BC ,  StJB)  3  ,  [ORBS] ,  [AAR]  , 

[BDELDVJ  ,  [AMAT]  )  ; 


NITER 

BC 

MINDEX 

SOB 

CONST 

NDV 

SXM 

BGPDT  (BC) 

STABCF 

[PGAA] 

[LHSA (BC, SOB)] 
[RESA (BC , SOB) ] 
[DRHS ] 

[AAR] 

[DDELDV] 


[AMAT] 


Design  iteration  number  (Integer,  Input) 

The  boundary  condition  identification  number  (Integer,  Input) 

Mach  number  index  for  the  boundary  condition  to  recover  the  proper  sta¬ 
bility  coefficient  data  (Integer,  Input) 

The  subscript  identifier  for  the  current  SAERC  subcases  (Integer,  Input) 

Relation  of  constraint  values  (Character,  Input) 

The  number  of  global  design  variables  (Integer,  Input) 

The  symmetry  flag  for  the  current  SAEBO  subcases  (Integer,  Input) 

Relation  of  basic  grid  point  coordinate  data  (Character.  Input'; 

Relation  of  rigid  stability  coefficient  data  (Character,  Input) 

Partitioning  vector  used  to  obtain  g-set  active  displacement  and  accelera¬ 
tion  vectors  for  all  static  aero  subcases  that  have  active  trim  parameter, 
stress,  strain  and/or  displacement  constraints.  (Input) 

Modified  inertia  matrix  (Character,  Input) 

Modified  applied  load  matrix  (Character,  Input) 

Matrix  entity  containing  the  sensitivity  of  [RBSA]  to  the  design  variables 
(Character,  Input) 

Matrix  entity  containing  the  sensitivities  of  structural  accelerations 
either  zero  (for  fixed  accelerations)  or  from  solution  of 
LHSA* AAR  a  RESA*DDELDV  +  DRHS  (Output) 

Matrix  entity  containing  the  sensitivity  of  the  configuration  parameters 
to  the  design  variables.  Either  zero  (for  fixed  control  parameters)  or 
from  the  solution  of 

LHSA*AAR  =  RHSA*DD£LBV  +  DRHS  (Output) 

Matrix  entity  containing'  die  sensitivities  of  the  active  aeroelastic  control  pa¬ 
rameter  (DCxatTiQj)  constraints  to  the  design  variables  (Character,  Output) 
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Application  Calling  Sequence: 

None 

Method: 

First  the  case  relation  is  read  for  the  saero  subcases  in  the  boundary  condition.  Then  the  stabcf 
entity  is  read  for  the  terms  associated  with  the  current  mindex.  Then  the  TRXK,  control  linking  and 
control  effectiveness  data  are  read.  Finally,  the  CONST  relation  for  the  active  DCQNTKM,  stress  and 
displacement  constraints  associated  with  the  current  subscript  value  are  read  into  memory.  Then  the 
number  of  trim  subcases  (active/associated  with  sob)  is  determined  and  the  pgaa  matrix,  is  read  and 
the  number  of  active  subcases  is  determines.  The  number  of  columns  in  the  DRH3  matrix  (=NDV*number 
of  active  subcases  for  this  sob  value)  is  determined. 

At  this  point,  an  trim  solution  very  similar  to  the  one  done  in  the  SAERO  analysis  module  is  performed 
to  solve  for  the  AAR  rigid  body  acceleration  derivatives  and  the  DDELBV  trim  parameter  sensitivities. 
The  orbs  matrix  is  difficult  to  deal  with  since  it  must  be  partitioned  for  each  subcase  to  just  the  ndv 
columns  associated  with  the  subcase  under  consideration.  (Just  as  in  saero,  each  subcase  must  be  solved 
for  independently  since  the  effectiveness  and  control  linking  are  subcase  dependent.)  Given  the  correct 
ndv  columns  in  ORBS,  the  following  matrix  expression  is  available: 


“*««  LHSrx' 

'SH3fu  »»£.' 

DRHSj 

^Scncnm 

RHS^u  RKSks 

T 

ORBS. 

k_ 

Where: 

Represents: 

F+K 

Number  of  sufort  point  DOF 

F 

Set  of  free  accelerations,  AR 

K 

Set  of  known(FIXED)  accelerations,  AR 

U+S 

Number  of  AERO  parameters 

u 

Set  of  unknown  parameters 

s 

Set  of  set(FiX5Q)  parameter's 

Note  that  ARtnown  and  0EL3  sensitivities  are  aero  by 
definition. 

These  equations  must  be  rearranged  to  get  free  accelerations  and  unknown  delta’s  on  the  same  side  of 
the  equation: 


-a*3  J 

— LHS__  RES  . 

£X  f  s 

'o' 

fDRHS  ' 

.  !  f 

i - 

O 

M 

r 

i _ 

-LB3VV  SESV 

0 

DRHS 

We  must  handle  the  degenerate  case  where  all  accelerations  or  all  delta’s  are  known.  Once  the  solution 
is  obtained,  the  free  acceleration  derivatives  and  unknown  trim  parameter  derivatives  are  unscrambled 
and  loaded  into  subcase  specific  AAR  and  DDELDV  entities. 
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Finally,  if  any  active  dcontrm  constraints  exist,  the  AAR  or  DD2LDV  matrix  for  the  current  subcase  is 
used  to  compute  the  AMAT  terms  for  them. 

Upper  bound 


REQ  >0.0 

DG/DX  = 

SENS  / 

REQ 

REQ  <0.0 

DG/DX  = 

-  SENS 

/  REQ 

REQ  =0.0 

DG/DX  = 

SENS 

Lower  bound 


REQ  >0.0 

DG/DX  = 

-  SENS 

/  REQ 

REQ  <  0.0 

DG/DX  = 

SENS  / 

REQ 

REQ  =0.0 

DG/DX  = 

-  SENS 

Where  REQ  is  stored  in  the  sensphmi  attribute  of  CONST  and  sens  is  the  raw  acceleration  or  deflection 
sensitivity. 

The  final  operation  for  the  subcase  is  to  merge  the  NDV  aar  and  ddeldv  columns  for  the  current  subcase 
into  the  output  matrices.  The  output  matrices  have  NDV  columns  for  each  active  subcase  in  subcase  order 
of  saero  disciplines  in  the  case  relation. 

Design  Requirements: 

1.  This  module  assumes  that  either  strength  and/or  DCONTRM  constraints  exist  for  the  static  aeroelastic 
analyses  in  the  current  boundary  condition. 

Error  Conditions: 

None 
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Engineering  Application  Module:  AMP 

Entry  Point:  AMP 
Purpose: 

lb  compute  the  discipline  dependent  unsteady  aerodynamic  matrices  for  flutter,  gust  and  blast  analyses. 
MAPOL  Calling  Sequence: 

CALL  AMP  (  [AJJTL] ,  [D1JK] ,  [D2JK] ,  [SKJ] ,  [QKKL] ,  [QKJL] ,  [QJJL] ,  [AJJDC]  ) ; 

[AJJTL]  Matrix  containing  the  list  of  AiC  matrices  for  each  Mach  number,  reduced 

frequency  and  symmetry  option  in  transposed  form  (Input) 

[D1JK]  Real  part  of  the  substantial  derivative  matrix  (Input) 

[D2JK]  Imagine  7  part  of  the  substantial  derivative  matrix  (Input) 

[SKJ]  Integration  matrix  (Input) 

[QKKL]  Matrix  list  containing  the  matrix  product: 

[SKJ] * [TRANS (AJJT) ]-1*  (  [D1JK]  +  ik[D2JK]) 
used  for  flutter  and  gust  analyses  (Output) 

[QKJL]  Matrix  list  containing  the  matrix  product: 

[SKJ]  *  [TRANS (AJJT) ] _1 
used  for  gust  analyses  (Output) 

[QJJL]  Matrix  list  containing  the  matrix  product: 

[TRANS (AJJT) ]  _1 

used  for  nuclear  blast  analyses  (Output) 

[ajjdc]  Optional  scratch  entity  to  store  the  intermediate  matrix  product: 

[TRANS (AJJT) ]  _1  *  (  [D1JK]  +  ik[D2JK]) 
from  the  QKK  matrix  calculation  (Output) 

Application  Calling  Sequence: 

None 

Method: 

The  AMP  module  begins  by  querying  the  CASE  relation  and  determining  if  any  oust,  BLAST  and/or 
FLUTTER  cases  exist.  If  any  of  these  disciplines  or  options  are  selected,  the  AMP  module  proceeds  to 
compute  the  requisite  matrix  lists.  The  FLUTTER  bulk  data  and  the  UNMK  data  are  prepared  in  core  using 
the  prefl  and  prunmk  utilities.  As  a  separate  step,  the  second  record  of  the  Ui»4K  is  queried  to  determine 
the  number  of  aerodynamic  interference  groups  in  the  model  so  that  the  structure  of  the  aerodynamic 
matrices  can  be  interpreted  correctly.  As  a  final  initialization  task,  the  existence  of  both  subsonic  and 
supersonic  matrices  is  checked  since  the  D1JK  and  D2JK  matrices  are  different  for  subsonic  and 
supersonic  aerodynamics  due  to  the  different  control  point  used. 

The  module  then  begins  to  loop  through  the  set  of  m-k  pairs  in  the  UNMK  entity.  For  each  new  Mach 
number/symmetry  group  (denoted  by  the  sqrp  flag),  the  UNMK  and  CASE  relation  data  formed  in  PRUNMK 
is  checked  to  determine  which  of  the  three  discipline  dependent  matrix  lists  are  to  be  formed  for  the 
reduced  frequencies  associated  with  the  Mach  number  and  symmetry  group.  If  FLUTTER  or  GUST 
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disciplines  are  associated  with  the  Mach/SGRP  set,  the  corresponding  NJ  columns  of  SKJ  are  extracted 
from  the  SKJ  list  input  in  the  calling  sequence.  Also,  the  NJ  columns  of  ajjtl  are  extracted  irrespective 
of  the  discipline  options.  Finally,  if  the  QKK  matrix  is  to  be  formed,  the  dijk  and  D2JK  are  processed 
depending  on  the  presence  of  both  subsonic  and  supersonic  forms.  This  processing  consists  of  the 
extraction  of  the  second  NK  columns  of  DIJK  and  D2  JK  on  the  first  supersonic  Mach  number  encountered. 
The  appropriate  matrices  are  then  added  together  for  the  current  reduced  frequency  as: 

[DCJK]  =  [DIJK]  +  (0+ik) [D2JK] 

At  this  point,  the  module  is  ready  to  deal  with  the  AJJT  matrix  previously  extracted.  The  processing  of 
this  matrix  depends  on  the  presence  of  different  interference  groups  in  the  unsteady  aerodynamics 
model.  For  the  case  with  a  single  interference  group,  the  extracted  AJJT  matrix  is  transposed  and  then 
decomposed.  If  the  QKK  matrix  is  required,  the  following  matrix  is  formed  using  the  GFBS  utility: 

[SCRDC]  =  [AJJ]  ~X  [DCJK] 

If  either  the  QJJ  or  QJK  matrices  are  needed,  the  actual  inverse  of  AJJ  is  formed  and  stored  as  QJJ.  If 
the  qjk  matrix  is  needed  as  well,  the  QJJ  matrix  is  used  to  form  the  QJK  matrix  as: 

[QJK]  *  [SKJ]  [QJJ] 

If  there  is  more  than  one  interference  group,  the  alternate  path  is  used  to  obtain  the  scrdc,  QJJ  and/or 
QJK  matrices.  In  this  path,  a  loop  is  performed  for  each  interference  group.  The  second  record  of  the 
onmk  entity  is  used  to  determine  the  number  of  j-set  and  k-set  degrees  of  freedom  in  the  current 
interference  group.  These  are  used  to  generate  the  Pi?. TJ  partitioning  vector  for  the  AJJ  matrix.  This 
vector  acts  as  a  floatingN JG-sized  vector  to  extract  the  WJG  columns  and  rows  associated  with  the  current 
group.  The  AJJT  matrix  is  then  partitioned,  transposed  and  decomposed  to  form  AJ  JG.  If  the  QKK  matrix 
is  needed,  the  PRTK  partitioning  vector  is  also  required.  This  vector  is  a  floating  NKG-sized  vector  to 
extract  the  NKG  columns  or  rows  for  the  current  interference  group.  The  DCJK  matrix  is  then  partitioned 
for  the  current  group  and  used  as  follows: 

[AJJDCG]  =  [AJJG]  -1  [DCJKG] 

The  inmat  utility  is  then  used  to  merge  this  matrix  into  the  scrdc  matrix  using  the  interference  group 
partitioning  information.  As  before,  if  the  QJJ  or  QJK  matrices  are  needed,  the  AJJG  matrix  is  inverted 
and  stored  as  QJJG.  The  INMAT  utility  merges  this  matrix  into  the  QJJ  matrix.  At  the  conclusion  of  the 
interference  group  loop,  the  scrdc  and  QJJ  matrices  ure  complete.  At  this  point,  the  logic  recombines 
for  both  paths.  If  the  QKK  matrix  is  needed,  the  scrdc  matrix  is  used  to  compute  QKK  as: 

[QKK]  =  [SKJ] [SCRDC] 

which  is  then  appended  onto  the  list  of  QKK  matrices,  qkkL.  If  the  QJK  matrix  is  needed,  the  QJJ  matrix 
is  used  to  comput  QJK  as: 

[QJK]  *  [SKJ]  [QJJ] 

which  is  then  appended  onto  the  list  of  QJK  matrices,  QJKL.  Finally,  the  computed  QJJ  matrix  is 
appended  to  the  qjjl  matrix  list  if  it  is  required  for  this  m-k/SGRP  matrix.  The  module  then  continues 
with  the  next  m-k/SGRP  matrix  in  the  UNMK  entity.  Note  that  all  the  matrix  lists  are  formed  in  the  order 
the  m-k/SGRP  data  appear  in  the  UNMK,  although  each  list  need  not  have  all  sets.  Once  the  entire  set  of 
mk/SGRP  sets  in  the  UNMK  have  been  processed,  the  module  terminates  by  destroying  the  numerous 
scratch  matrices  used  in  the  computations. 
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Design  Requirements: 

I.t  The  PLOTTER  bulk  data  entries  and  the  case  relation  are  used  to  determine  the  set  of  m-k/symnietry 
pairs  for  each  aerodynamic  matrices  required  for  each  discipline.  The  data  on  the  data  base  data  base 
will  be  used  to  determine  the  set  of  matrices  to  be  computed. 

Error  Conditions: 

None 
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Engineering  Application  Module:  ANALINI  rf 


Entry  Point:  ANINIT 


Purpose: 


Initializes  the  final  analysis  pass.  This  module  should  be  called  at  the  beginning  of  the  final  analysis 
loop  to  set  parameters  as  needed  for  that  pass. 


MAPOL  Calling  Sequence: 
CALL  ANALINIT; 


Application  Calling  Sequence: 

None 

Method: 

This  module  is  called  to  perform  any  actions  needed  to  transition  from  the  optimization  segment  of 
ASTROS  to  the  analysis  segment.  Currently,  the  only  action  taken  by  the  module  is  to  overwrite  the 
portion  of  the  SUBTITLE  that  is  used  to  denote  the  design  iteration  number  (set  in  ITERINIT)  with  the 
label  "FINAL  ANALYSIS  SEGMENT." 

Design  Requirements: 

1.  This  routine  overwrites  the  characters  88-128  of  the  SOBTIT  variable  in  /QUTPT2/  used  by  UTPAEE. 
No  other  application  modules  except  OiT  should  modify  the  TITLE,  SUBTIT,  label  variables  beyond 
the  72nd  character,  since  these  fields  are  used  to  set  dates,  page  numbers  and  subcase  information. 

Error  Conditions: 

None 
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Engineering  Application  Module:  AROSNSDR 

Entry  Point:  AROSDR 

Purpose: 

MAPOL  director  for  saero  sensitivity  analyses 
MAPOL  Calling  Sequence: 


CALL  AROSNSDR  ( 

NITER,  BC,  SOB,  LOOP,  MINDEX,  CONST,  SXM,  NGDR,  [PSDRG(BC)3, 
[OAG(BC) ] ,  [AAG{BC)3 ,  ACTOAG,  [OGA] ,  [AGA] ,  [PGAA] ,  [PGAOl , 
PCAA,  [OAGC (BC , SOB) ] ,  [AAGC (BC , SOB) ] ,  ACTAEFF ,  [AOAGC] , 

[AAAGC] ,  PCAE  ) ; 

NITER 

Current  iteration  number.  (Input,  Integer) 

BC 

Current  boundary  condition  number.  (Input,  Integer) 

SOB 

Current  static  aeroelastic  subscript  number.  (Input,  Integer) 

LOOP 

A  logical  flag  set  to  indicate  whether  additional  MINDEX  subscripts  are 
needed  to  complete  the  processing  of  all  the  active  Mach  number/Symme- 
try  conditions  on  all  the  trim  entries.  One  pass  for  each  unique  active 
Mach  number  will  be  performed  with  MINDEX  set  as  appropriate  for  the 
active  pass  until  this  routine  returns  LOOP*FALSE.  (Logical,  Output) 

MINDEX 

Mach  number  index  value  of  the  current  pass.  (Output,  Integer) 

CONST 

Relation  of  design  constraints.  (Input) 

SXM 

Symmetry  flag  for  the  current  pass.  Either  1  for  symmetric  or  -I  for  anti¬ 
symmetric.  (Output,  Integer) 

NGDR 

Denotes  dynamic  reduction  in  the  boundary  condition. 

*  0  No  GDR 

*  -1  OR  is  used 
(Input,  Integer) 

[PGDRG(BC) 3 

A  partitioning  vector  that  removes  the  additional  OR  scalar  points  from 
the  g-set  sized  displacement  and  acceleration  vectors.  Required  only  if 
NGDR  *  0.  (Input) 

tOAG{BC}] 

g-set  displacement  vector  for  all  static  aero  subcases  in  the  current  bound¬ 
ary  condition.  (Input) 

[AAG (BC) 1 

g-set  acceleration  vector  for  all  static  aero  subcases  in  the  current  bound¬ 
ary  condition.  (Input) 

ACTOAG 

Logical  flag  that  is  set  to  TRDE  if  there  are  any  active  constraints  that  re¬ 
quire  the  displacements  or  accelerations.  Those  constraints  are  trim  pa¬ 
rameters,  stresses,  strains  and  displacements.  (Output,  Logical) 

[UGA] 

Reduced  g-set  active  displacement  vectors  for  all  static  aero  subcases  that 
have  active  trim  parameter,  stress,  strain  and/or  displacement  con¬ 
straints.  This  is  a  subset  Gf  the  columns  of  ;UAG  (BC)  ]  and  does  not  in¬ 
clude  the  GDR  scalar  points,  if  any  (Output) 
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[AGA] 

[PGAA] 

[PGAD] 

PCAA 

[UAGC (BC , SOB) ] 

[AAGC (BC , SUB) ] 

ACTAEFF 

[AUAGC ] 

[AAAGC] 

PCAE 


Reduced  g-set  active  acceleration  vectors  for  all  static  aero  subcases  that 
have  active  trim  parameter,  stress,  strain  and/or  displacement  con¬ 
straints.  This  is  a  subset  of  the  columns  of  ;AAQ  (BC)  3  and  does  not  in¬ 
clude  the  GDR  scalar  points,  if  any  '.Output) 

Partitioning  vector  used  to  obtain  [UG&j  and  [AGA]  from  [UAG(BC)  ] 
and  [AAG  (BC)  ] .  (Output) 

Partitioning  vector  relative  to  [UAG  (EC)  ]  and  [AAG  (BC)  ]  that  marks 
the  displacement/acceleration  columns  associated  with  subcases  having 
active  stress,  strain  or  displacement  constraints  This  vector  will  be  iden¬ 
tical  to  [PGAA]  unless  there  are  subcases  in  which  DCOOTBM  constraints 
are  active  and  no  stress,  strain  or  displacement  comtiaints  are  active. 
(Output) 

An  unstructured  entity  with  one  word  for  each  active  stress,  strain  or  dis¬ 
placement  constraint  in  the  current  subscript  related  subcases.  That 
word  is  the  subcase  id  associated  with  the  constraint.  (Output) 

g-set  pseudodisplacement  vectors  (displacement  fields  due  to  loads  cris- 
ing  from  unit  values  of  trim  configuration  parameters)  for  all  aeroelastic 
effectiveness  constraints.  (Input) 

g-set  pseudoacceleration  vectors  (acceleration  fields  due  to  loads  arising 
from  unit  values  of  trim  configuration  parameters)  for  all  aeroelastic  effec¬ 
tiveness  constraints.  (Input) 

Logical  flag  that  is  set  to  TRUE  if  there  are  any  acti  ve  constraints  that  re¬ 
quire  the  pseudodisplacements  or  pseudcaccelerations.  Those  constraints 
are  dconale,  DCONCLA  and  ncoNSCF.  (Output,  Logical) 

Reduced  g-set  active  pseudodisplacement  vectors  for  afl  active  effective¬ 
ness  constraints.  This  is  a  subset  of  the  columns  of  [UAGC  (BC)  ]  and  does 
not  include  the  GDR  scalar  points,  if  any  (Output) 

Reduced  g-set  active  pseudoacceleration  vectors  for  all  active  effective¬ 
ness  constraints.  This  is  a  subset  of  the  columns  of  [AAGC  (BC)  ]  and  does 
not  include  the  GDR  scalar  points,  if  any  (Output) 

An  unstructured  entity  with  one  word  for  each  active  effectiveness  con¬ 
straint  (D COHALE,  DCONCLA,  DCONSCF)  in  the  current  subscript’s  related 
subcases.  That  word  is  the  column  id  of  the  first  column  associated  with 
the  constraint.  (Output) 


Application  Calling  Sequence: 
None 


Method: 

This  module  treats  two  distinct  families  of  aeroelastic  constraints  for  the  current  boundary  condition 
and  subscript  number:  the  active  aeroelastic  effectiveness  constraints  DCONALE,  DCONCLA  and  DCONSCF; 
and  the  active  displacement  dependent  constraints  DCONTRM,  DCONDSP ,  stress  and  strain.  Two  parallel 
sets  of  partitioning  operations  take  place  to  extract  the  active  pseudodisplacements  needed  for  effective¬ 
ness  constraints  and  active  displacements  needed  for  the  displacement-dependent  constraints.  The 
control  information  for  the  presence  or  absence  of  each  type  of  constraint  and  the  additional  control 
information  to  extract  data  from  downstream  entities  is  also  prepared  for  each  constraint  family.  Finally, 
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the  need  to  loop  through  another  subscript  value  is  determined  and  the  LOOP  variable  is  output,  LOOP 
will  be  false  after  the  last  needed  AROSN3DR  call  for  the  current  BC. 

First  case  is  queried  to  obtain  the  TRIM  identification  number  and  symmetry.  Then  TRIM  is  read  to 
obtain  the  subscript  numbers,  MINDEX  values  and  subcase  ids  for  each  SAERO  subcase  in  the  current  BC. 
These  data  are  then  assembled  into  a  master  table  containing  the  trim  identification  number,  the 
subscript  number  and  the  subcase  id. 

The  const  relation  is  then  read  to  count  the  number  of  active  stress,  strain,  displacement,  aileron 
effectiveness,  lift  effectiveness,  stability  coefficient  and  trim  parameter  constraints.  A  loop  over  each 
CONST  entry  i»  then  made  to  assemble  the  partitioning  vectors  and  control  information  for  sensitivity 
computations.  Each  family  of  constraints  is  treated  separately. 

For  effectiveness  constraints,  the  DISPCOL  attribute,  in  CONST  is  used  to  build  a  partitioning  vector  for 
the  active  pseudodisplacements  and  accelerations.  The  partitioning  vector  is  later  destroyed  but  the 
active  column  numbers  are  stored  as  a  contiguous  string  of  numbers  and  written  to  PC3VE.  For  lift 
effectiveness  constraints  there  is  one  tJAGC/ AAGC  column  for  each  applied  constraint:  the  disp/accei  due 
to  a  unit  angle  of  attack.  For  aileron  effectiveness,  there  are  two  columns:  the  first  due  to  unit  control 
surface  deflection  and  the  second  due  to  unit  roll  rate.  For  stability  coefficients,  there  is  one  column  due 
to  a  unit  deflection  of  the  constrained  parameter.  As  the  constraints  are  looped  over,  only  those  with  the 
current  subscript  value  are  considered.  Those  will  lower  subscript  values  have  already  been  processed 
and,  if  any  active  constraints  are  found  with  a  higher  subscript  value,  the  LOOP  flag  is  set  to  TRUE  to 
ensure  another  pass  is  done. 

A  similar  path  exists  for  the  displacement-dependent  constraints  except  the  matrices  being  partitioned 
are  the  actual  displacement  and  acceleration  fields.  Separate  partitioning  vectors  are  assembled  for  1) 
active  columns  due  to  all  displacement  dependent  constraints  (pgaa)  and  2)  active  columns  due  to  stress, 
strain  and  displacement  constraints  (PGUA).  Again,  previously  processed  subscripts  are  ignored  and 
LOOP  is  set  to  true  of  larger  subscripts  are  encountered. 

Finally,  the  assembled  partitioning  vectors  are  written  to  their  respective  entities  and  the  PCAE  and 
FCAA  entities  are  determined  from  the  partitioning  data  and  written  to  the  unstructured  entities.  The 
presence  of  active  constraints  in  the  effectiveness  family  or  displacement-dependent  family  is  then 
known  and  the  actaeff  and  actuag  flags,  respectively,  are  set. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Engineering  Application  Module:  AROSNSMR 

Entry  Point:  AROSMR 

Purpose: 

Merges  the  static  aero  sensitivities  for  each  subscript  (stored  in  the  matrix  [MATSUB] )  into  the  [MATOUT] 
matrix  in  case  order  for  active  subcases  rather  than  subscript  order  for  the  current  active  boundary 
condition. 

MAPOL  Calling  Sequence: 

CALL  AROSNSMR  {  BC,  SOB,  NDV,  [PGAA] ,  [PGAU] ,  [MATOUT],  [MATSUB]  ); 

Current  boundary  condition  number.  (Input,  Integer) 

Current  static  aeroelastic  subscript  number.  (Input,  Integer) 

Number  of  design  variables.  (Input, Integer) 

Partitioning  vector  used  denoting  active  displacement  fields  for  the  cur¬ 
rent  boundary’s  static  aeroelastic  subcases.  (Input) 

Partitioning  vector  used  denoting  active  displacement  fields  that  are  ac¬ 
tive  due  only  to  stress,  strain  and  displacement  constraints  for  the  cur¬ 
rent  boundary’s  static  aeroelastic  subcases.  (Input) 

On  input,  MATOUT  must  contain  the  merged,  reordered  displacement  or  ac¬ 
celeration  sensitivities  for  all  the  subcases  processed  for  the  earlier  sub¬ 
script  values.  On  output  the  3UB’th  subscript  is  included.  Thie  matrix  will 
contain  one  column  for  each  active  vector  for  the  1st  design  variable,  fol¬ 
lowed  by  another  set  for  the  second  and  so  on.  The  order  of  the  vectors 
within  each  variable’s  set  will  be  the  order  of  the  saerg  subcases  in  the 
case  relation.  (Input  and  Output) 

The  input  matrix  of  displacement  or  acceleration  sensitivities  for  all  the 
subcases  processed  for  the  suB'th  subscript.  This  matrix  will  contain  one 
column  for  each  active  vector  associated  with  the  SUB’th  subscript  for  the 
1st  design  variable,  followed  by  another  set  for  the  second  and  so  on.  The 
order  of  the  vectors  within  each  variable’s  set  will  be  the  order  of  the 
trim  ids  appearing  in  the  trim  relation  associated  with  the  SUB’th  sub¬ 
script  value.  (Input) 

Application  Calling  Sequence: 

None 


BC 
SUB 
NDV 
I  PGAA] 

[PGAU] 

[MATOUT] 

[MATSUB] 


Method: 

First  the  CASu  relation  is  read  to  retrieve  the  trim  id’s  for  the  SAERO  subcases  in  the  current  boundary 
condition.  Tht  V".e  trim  relation  is  read  to  obtain  the  subcase  numbers  associated  with  each  trim  id 
having  the  current  3UB3cript  value.  Then  the  PGAA  and  pgua  vectors  are  read  into  memory  to  assist  in 
the  partitioning  operation. 

Then  the  MATSUB  ana  MATOUT  matrices  are  opened.  If  MATOUT  is  uninitialized  OR  if  SUB  »  1,  it  is 
initialized  (flushed  and  the  number  of  rows,  precision  and  form  set  to  those  ofMATSUB.  If  MATOUT  already 
exists  and  has  data  in  it,  a  scratch  matrix  is  created  to  hold  the  final  merged  data. 
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For  each  design  variable  in  the  model,  each  3 aero  case  entry  for  the  current  boundary  is  processed. 
For  each  CASE  entry,  the  partitioning  vector  PGAA  is  used  to  determine  if  it  ie  active  and  therefore  may 
have  a  column  in  either  MATSUB  or  MATOUT.  For  the  active  subcase  id,  the  TRIM  data  are  searched  to 
determine  the  subscript  number  associated  with  the  subcase.  If  the  subscript  is  less  than  SOB,  a  column 
from  MATOUT  may  be  taken  (if  it  was  stored  there  on  an  earlier  pass).  If  the  subscript  is  equal  to  SUB,  it 
may  be  stored  on  the  output  matrix  from  MATSUB.  If  greater  than  SUB,  it  is  ignored  till  later  passes. 

Once  a  column  is  identified  as  active  inMATSUB  (PGAA  indicates  active  and  subscript  =  SUB),  an  additional 
check  is  made  to  see  if  the  column  is  active  in  pgua.  Only  those  columns  that  are  active  in  pgua  are 
copied  to  MATOUT.  This  filtering  is  done  to  limit  the  amount  of  computational  effort  in  the  stress,  strain 
and  displacement  constraint  sensitivity  computations  that  proceed  using  the  MATOUT  matrix.  The 
MATSUB  columns  that  are  active  due  to  DCCNTHM  constraints  are  no  longer  needed  as  these  sensitivities 
are  assumed  to  have  been  computed  already  in  the  AEROSEN3  module. 

Once  the  final  matrix  is  formed,  if  MATOUT  had  had  data  in  it,  the  name  of  the  scratch  matrix  that  was 
loaded  is  switched  with  that  of  MATOUT.  The  scratch  entity  is  then  destroyed. 

Design  Requirements: 

1.  The  assumption  is  that  each  MATSUB  matrix  contains  the  results  from  the  "Stffl"th  subscript  value  in 
the  order  the  trim  id’s  for  that  SUB  appear  in  the  TRIM  relation. 

2.  The  same  MATOUT  matrix  must  be  passed  into  the  AROSHSMR  module  on  each  call  since  the  columns 
associated  with  earlier  subscript  values  are  read  from  MATOUT  into  a  scratch  entity.  The  merged  matrix 
that  results  is  then  replaces  the  input  MATOUT. 

3.  The  aerosens  module  is  called  upstream  of  the  abqsnsmr  module  to  process  active  dcontkk 
constraints  for  the  current  subscript.  Thus,  those  columns  that  are  active  only  for  DCOKTEM  constraints 
may  be  filt  ered  out  for  the  downstream  processing  of  stress,  strain  and  displacement  constraints. 

Error  Conditions: 

None 
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Engineering  Application  Module:  BCBGPDT 

Entry  Point:  BCBGPD 

Purpose: 

Builds  the  boundary  condition-dependent  grid  point  coordinate  relation  bgpdfc  for  the  specified  boundary 
condition. 

MAPOL  Calling  Sequence: 

CALL  BCS3PDT  (  3 C  ,  3SISSB  ,  BQRBT(BC)  ,  ESIZE (BC)  j; 


BC 

Boundary  condition  number.  (Integer,  Input) 

GSISSB 

Basic  g-set  size  (the  size  independent  of  GCR-added  scalar  points). 

(Integer,  Input) 

BGPDT(BC) 

Relation  of  basic  grid  po.nt  data  for  th®  boundary  condition  (including 
any  sxtra  points  but  excluding  SDR  scalar  points  which  may  be  added  by 
the  OR  module).  (Output) 

ESIZE (BC) 

Number  of  extra  point  DOP  defined  for  the  boundary  condition. 

(Integer,  Output) 

Application  Calling  Sequence: 

None 

Method: 

The  invariant  basic  grid  point  data  is  read  from  the  BGPDT  relation  (an  unsubscripfcsd  relation  that  is 
formed  in  ifp).  The  user’s  extra  points  selected  in  the  CASE  relation  are  then  appended  in  memory  and 
sorted  on  external  id.  Uniqueness  of  the  external  id’s  are  checked  and  the  new  BGFDT  (BC)  is  written. 

Design  Requirements: 

1.  The  invariant  BQPBT  must  exist  on  the  data  base.  It  is  a  hidden  output  from  the  XFP  module. 
Error  Conditions: 

1.  Nonunique  grid/efoint  id's  are  flagged. 
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Engineering  Application  Module:  BCBULK 

Entry  Point:  BCBULK 

Purpose: 

Builds  boundary'  condition- depende&t  fatness,  transfer  functions,  and  initial  conditions 
MAPOLCaillm*  Sequence: 

££&  %dkms.  ;t  .BC^V?S2tSffeS^  ^^PST{&Ci  (  t?3g?(S2)  )  ; 

'  *■'$*'  ??  ,  , 

BS  Boundary  condition  iden'd^cstion  number,  (integer,  Input) 

BSISE  (SC)  The  size  of  the  physical  set  for  the  current  boundary  condition.  Gutter,  Input) 

asP&T  (SC)  ,  ,  The  relation  of  basis  gftd  point  data  for  the  current  BC  (including  any  se- 

.  lectad  es^rg'pohits).  (Input) 

,  -puis  (BC)  )  |f  % v"  l|&^s|s^Sfeured  entity  of  DOF  masks  for  all  the  points  in  the  current 


boundary  conditions.  (Input) 


Application  Calling  Sequence: 


Ndne . 
Method: 


All  the  outputs  from  this  routine  are  hiddsn  —  meaning  that  they  do  not  appear  in  the  call.  The  purpose 
of  this  module  is  to  assemble  those  data  that  depend  on  the  boundary  condition  selection  of  extra  points. 

For  the  data  of  each  type  that  is  referenced  in  SSBK  for  the  current  boundary  condition,  the  data  are 
retrieved  from  the  bulk  data.relati.ena  that  were  loaded  in  1VS  and  are  error  checked  relative  to  the  set 
of  DOF- that  comprise  the  current  boundary  condition.  The  following  hidden  entities  are  output: 


BULK  DATA 

- . .  . — 

SUBROUTINE 

GENERATED  ENTITY  j 

DLONLT 

PR2D0I. 

(JDLOIif  | 

DM13 

m&mG 

named  matrix  entities  ] 

TS 

HRETF 

2FD&2A  \ 

1C 

PSSIC 

ICDS.T&  S 

In  each  case,  these  entities  contain  only  those  data  that  relate  to  the  current  boundary  condition.  They  will 
be  replaced  in  subsequent  boundary  conditions  and/or  iterations  with  the  appropriate  data  on  each  pass. 

Design  Requirements: 

None. 

Error  Conditions: 


1.  Initial  error  checking  of  each  bulk  data  entry  type  is  performed  within  this  module. 


Engineering  Application  Module:  BLASTDRV 

Entry  Pohit:  BLSDKV 

Pin-pose: 

lb  compute  an  aircraft’s  transient  response  to  a  nuclear  blast. 

MAPOL  Calling  Sequence: 

CALL  BLASTBS.V  {  BC ,  [GENM]  ,  [GENK]  ,  [GENEA]  ,  [GENQL]  ,  [DELB]  ,  [UBDB]  , 
[DKNWSH]  ,  [SLPMQD]  ,  [BIAS]  ,  [OBLASTI]  )  ; 


BC 

Boundary  condition  ID  (Integer,  Input) 

tGEEM] 

Generalized  mass  matrix  (Input) 

[GENK] 

Generalized  stiffness  matrix  (Input) 

[GENFA] 

Mode  on  box  generalized  forces  (Input) 

[GENQL] 

Mode  on  box  aeroelastic  corrections  (Input) 

[DELB] 

Trim  vector  of  initial  conditions  (Input) 

[DBDB] 

Vector  of  initial  accelerations  (Input) 

[DWNWSH] 

Matrix  of  downwash  vectors  for  unit  angle  of  attack  and  elevator  (Input) 

[SLPMOD] 

Matrix  of  slopes  at  box  centers  due  to  structural  modes  (Input) 

[ELA3] 

Matrix  of  initial  modal  displacements  (Input) 

[UBLASTI] 

Matrix  of  blast  response  vectors.  For  each  time  step,  displacement,  veloc¬ 
ity  and  acceleration  vectors  are  stored  (Output) 

Application  Calling  Sequence: 

None 

Method: 

The  module  obtains  solution  control  information  from  the  CASE  relation,  the  reference  chord  from  aero 
and  blast  parameters  from  BLAST.  SENE,  GENQL,  DWNWSH,  SLSMOD  and  aerodynamic  geometry  data 
are  read  into  core.  Initial  conditions  are  set  up  and  a  call  to  subroutine  A3T6AS/D  initializes  the  blast- 
calculation.  The  TSTEP  data  are  then  read  in  and  a  call  to  XBLSTS/D  calculates  the  blast  intercept  time. 

Initial  response  vectors  are  written  to  the  dblasti  matrix  and  a  call  to  subroutine  blvels/D  calculates 
the  downwash  at  the  aerodynamic  boxes  and  a  call  to  AST6AS/D  gets  the  initial  load.  Aloop  on  the  time 
steps  -a  then  begun.  ANewmark-Beta  algoiithm  is  applied  to  calculate  the  transient  response.  Within 
the  time  loop,  calls  to  BLVELS/D  and  AST6AS/D  determine  the  downwash  vector  and  the  response, 
respectively.  Data  are  written  to  UBLASTI  as  specified  by  the  TSTEP  input.  Once  all  the  time  steps  have 
been  computed,  scratch  entities  are  destroyed  and  control  is  returned  to  the  executive. 
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L  ™S  ^0dde  “rae  a%r1Br^STFIT  and  biasttrih.  The  module  is  called  in  both  the  optimize 

and  the  analyze  phase  of  the  MAPOL  sequence,  but  produces  no  constraint  information  for  the 
optimization  task. 

Error  Conditions: 
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Engineering  Application  Module:  BIASTFI T 
Entry  Point:  INTRF 


Purpose: 

To  compute  the  interpolated  time  domain  steady  state  and  time  dependent  aerodynamic  influence 
coefficients  for  blast  analyses  based  on  unsteady  aerodynamics  computed  in  the  time  domain. 

MAPOL  Calling  Sequence: 

G&LL  BLASTFTT  (  BC,  [QJJL]  ,  [MATTR]  ,  [MATSS]  ,  BQDP,  [BFRC],  [DWNWSH] , 

HSIZE(BC),  [XD2] ,  [MPART] ,  [UGTKA] ,  [BLGTJA] ,  [BL3TJA]  ); 


BC 

[QJJL] 

[MATTR] 

[MATSS] 

BQDF 

[BFRC] 

[DWKWSH] 

HSIZE (BC) 
[ID2] 

[MBART] 

[UGTKA] 

[BLGTJA] 

[BLSTJA] 


Boundary  condition  ID  (Integer,  Input) 

Aerodynamic  influence  coefficient  matrices  in  the  frequency  domain 
(input) 

Aerodynamic  influence  coefficient  matrix  list  in  the  time  domain  (Output) 
Steady  stat  aerodynamic  influence  coefficient  matrix  (Output) 

Blast  dynamic  pressure  (Real,  Output) 

Matrix  of  aerodynamic  forces  due  to  specified  rigid  body  motions  (Output) 

Matrix  of  downwash  components  due  to  specified  rigid  body  motions 
(Output) 

Number  of  normal  modes  to  be  used  in  the  analysis  (Integer,  Output) 

An  identity  matrix  required  for  performing  trim  analysis  in  the  MAPOL 
sequence  (Output) 

A  partitioning  vector  required  for  performing  trim  analysis  in  the 
MAPOL  sequence  (Output) 

Unsteady  spline  matrix  (Input) 

Spline  matrix  for  transforming  blast  forces  (Output) 

Spline  matrix  for  transforming  displacements  and  slopes  (Output) 


Application  Calling  Sequence: 
None 


Method: 

Problem  parameters  are  first  obtained  from  the  CASE,  AERO  and  BLAST  entities.  A  call  to  ATMOS 
determines  the  dynamic  pressure  for  the  specified  flight  condition.  Aliat  of  reduced  frequencies  that  are 
available  for  the  specified  Mach  number  is  j-etrieved.  A  grand  loop  on  the  number  of  sending  boxes  is 
begun  with  a  call  to  DLIHDX  to  determine  the  geometry  of  the  sending  box.  A  secondary  loop  on  the 
receiving  bcx  starts  with  a  call  to  READOL  to  extract  the  QJJL  coefficients  for  the  receiving  and  sending 
boxes  for  all  the  reduced  frequencies.  These  data  are  then  processed  using  the  algorithm  described  in 
Appendix  B  of  the  Theoretical  Manual  to  compute  time  domain  coefficients.  Once  all  the  receiving  boxes 
have  been  computed,  a  column  of  MATSS  is  written  and  NBETA  columns  are  written  to  scratch  matrix 
blssc?  Once  the  bop  on  sending  boxes  has  been  completed,  the  BLSSCR  data  are  retrieved  in  the  order 
that  they  arc  required  in  MATTR  and  this  output  matrix  is  written.  A  call  to  BLSFRS/D  computes  matrices 
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required  in  the  trim  analysis.  Downwash  vectors  for  given  aircraft  parameters  (such  as  angle  of  attack) 
are  computed  and  stored  to  DWNWSE.  Premultiplication  of  the  downwash  vector  by  the  MATS 3  matrix 
computes  the  forces  due  to  the  aircraft  parameters  and  these  data  are  stored  in  BliSBRS/D.  Matrices 
ID2  and  MPART  are  created  and  the  UGTKA  matrix  is  partitioned  into  blgtja  and  blstja.  Control  is 
then  returned  to  the  driver  subroutine  and  then  to  the  executive. 

Design  Requirements: 

1.  Must  follow  the  amp  module.  It  it  is  convenient  to  group  this  module  with  the  blasttrim  ana 
BLA3TDKV  modules  since  they  rely  on  blastfit  outputs. 

Error  Conditions: 


None 


Engineering  Application  Module:  BLASTRIM 

Entry  Point:  BLSTRM 

Purpose: 

Performs  a  trim  analysis  prior  to  performing  a  transient  response  to  a  nuclear  blast. 

MAPOL  Calling  Sequence: 

CALL  BLASTRIM  (  BC,  [DEIM]  ,  [MRR(BC)3,  [URDB]  ,  [DELB]  ); 

BC  Current  boundary  condition  ID  (Integer,  Input) 

[DELM]  Matrix  of  applied  loads  (Input) 

[MBR  (BC)  ]  Reduced  mass  matrix  (Input) 

[urdb]  Matrix  of  aircraft  accelerations  (Output) 

[DELB]  Matrix  of  trim  parameters  (Output) 

Application  Calling  Sequence: 

None 

Method: 

The  DEIM  and  mrr  matrices  are  read  into  core,  the  BLAST  identification  number  is  retrieved  from  the 
CASE  entity  and  the  corresponding  blast  parameters  are  read  from  the  blast  entity.  The  trim  equations 
are  then  solved  and  the  acceleration  and  trim  vectors  are  written  to  URDB  and  DELB,  respectively. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Engineering  Application  Module:  BOUND 
Entry  Point:  BOUND 


Purpose: 

Tb  return  flags  to  the  MAPOL  sequence  that  define  the  matrix  reduction  path  for  the  current  boundary 
condition. 


MAPOL  Calling  Sequence: 

G&LXi  BOCHD  (  BC,  GSIZE,  ESIZE(BC),  USET(BC)  ,  BLOAD,  BHASS,  DMODES,  BKSODE3, 
B3AERO,  BFLUTR,  BDXN,  BDRSP,  BDTR,  BMTR,  BDFR,  BMFR,  BOOST, 
BBIAST,  NMPC,  NSBC,  NCMIT,  NRSET,  NGDR  ); 


BC 


Boundary  condition  number  (Integer  .Input) 


GSIZE  The  number  of  degrees  of  freedom  in  the  structural  set  (Integer,  Input) 

ESZZS  (BC)  The  number  of  extra  point  degrees  of  freedom  in  the  boundary  condition 

(Integer,  Input) 

OSET  (BC)  The  unstructured  entity  defining  structural  sets  (Character,  Input) 


BLQAD 

BMASS 

DMODES 

BMODES 

BSAKRO 

BFLUTR 

BOTH 

BDRSP 

BDTR 

BMTR 

BDFR 

BMIR 

B30ST 


Static  load  flag;  «l  if  any  static  loads  in  the  current  boundary  condition 
(Integer,  Output) 

Mass  matrix  flag;  «1  if  the  mass  matrix  is  needed  for  any  discipline(s)  in 
the  current  boundary  condition  (Integer,  Output) 

Modes  discipline  flag;  *1  if  any  modal  dynam;c  response  discipline(s) 
(Integer,  Output) 

Modal  analysis  flag;  *1  if  any  disciplines  in  the  current  boundary  condi¬ 
tion  require  that  a  real  eigenanalyeis  be  performed  (Integer,  Output) 

Static  aeroelastic  flag;  if  any  static  aeroelastic  analyses  are  in  the  cur¬ 
rent  boundary  condition  (Integer,  Output) 

Flutter  discipline  flag;  *1  if  any  flutter  analyses  in  the  current  boundary 
condition  (Integer,  Output) 

Dynamics  flag;  =1  if  any  disciplines  requiring  dynamic  matrix  assembly 
are  in  the  current  boundary  condition  (Integer,  Output) 

Dynamic  response  flag;  *1  if  any  transient  or  frequency  response  analy¬ 
ses  in  the  current  boundary  condition  (Integer,  Output) 

Direct  Transient  Response  flag;  ®l  if  any  direct  transient  response  analy¬ 
ses  are  in  the  current  boundary  condition  (Integer,  Output) 

Modal  Transient  Response  flag;  *1  if  any  modal  transient  response  analy¬ 
ses  are  in  the  current  boundary  condition  (Integer,  Output) 

Direct  Frequency  Response  flag;  *1  if  any  direct  frequency  response 
analyses  are  in  the  current  boundary  condition  (Integer,  Output) 

Modal  Frequency  Response  flag;  *1  if  any  modal  frequency  response 
analyses  are  in  the  current  boundary  condition  (Integer,  Output) 

Gust  option  flag;  ®1  if  any  dynamic  response  disciplines  include  the  GUST 
option  in  the  current  boundary  condition  (Integer,  Output) 


110 


BBLAST 

NMS’C 
NS  PC 
NOMIT 
NRSET 
NGOR 


Blast  discipline  flag;  *1  if  any  blast  analyses  are  in  the  current  boundary 
condition  (Integer,  Output) 

Number  of  degrees  of  freedom  in  the  m-set,  (Integer,  Output) 

Number  cf  degrees  of  freedom  in  the  s-set,  (Integer,  Output) 

Number  of  degrees  of  freedom  in  the  o-set,  (Integer,  Output) 

Number  of  degrees  of  freedom  in  the  r-set,  (Integer,  Output) 

Denotes  dynamic  reduction  in  the  boundary  condition. 

=  0N0GDR 
=  -1  SDR  is  used 
(Input,  Integer) 

Application  Calling  Sequence: 

None 

Method: 

The  USET  entity  and  CASE  relation  are  read  to  determine  the  sizes  of  the  dependent  structural  sets  and 
to  ensure  that  no  illegal  combinations  of  disciplines  and  matrix  reduction  methods  reside  in  the  same 
boundary  condition.  The  matrix  reductions  and  analysis  steps  in  the  standard  MAPOL  sequence  are 
then  guided  by  the  flags  from  BOUND.  A  summary  of  the  structural  sets  is  printed  to  the  output  file 
followed  by  a  summary  of  the  disciplines  and  subcases  that  have  been  selected. 

Design  Requirements: 

1.  The  case  relation  must  be  filled  with  the  information  from  the  Solution  Control  Packet  by  the 
solution  module.  Also,  the  mkuset  module  must  have  loaded  the  uset  entity. 

Error  Conditions: 


None 
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Engineering  Application  Module:  DCEVAL 


Entry  Point:  DCEVAL 
Purpose: 

lb  evaluate  displacement  constraints  in  the  current  boundary  condition. 
MAPOL  Calling  Sequence: 

CALL  DCEVAL  {  NITER,  BC,  [US (BC) ] ,  CONST,  BSAERO  ); 


NITER 

BC 

[UG{BC)3 

CONST 

BSAERO 


Design  iteration  number  (Integer,  Input) 

Boundary  condition  ID  (Integer,  Input) 

Matrix  of  displacement  vectors  in  the  g-set  for  the  boundary  condition 
(Input) 

Relation  of  constraint  values  (Character,  Input) 

Static  aeroelastic  flag;  -1  if  this  call  is  associated  with  static  aeroelastic 
analyses.  (Optional,  Integer,  Input) 


Application  Calling  Sequence: 
None 


Method: 

The  module  first  determines  if  there  are  any  DCONST  options  for  a  static  (bsaero«0)  or  SAERO 
(BSAERO=l)  discipline  for  the  current  boundary  condition  and  terminates  if  there  are  none.  If  there  are, 
a  loop  is  made  through  all  the  subcases  for  the  current  boundary  condition  and  the  necessary 
displacement  constraint(s)  are  calculated  and  written  to  the  const  relation. 

Design  Requirements: 

1.  This  module  appears  within  the  analysis  portion  of  the  optimize  segment  of  the  MAPOL  sequence. 
It  is  within  the  analysis  boundary  condition  loop  and  must  follow  the  recovery  of  the  displacement  vector 
to  the  g-set. 

Error  Conditions: 

None 
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Engineering  Application  Module: 

Entry  Point:  DDLQAD 


DDLG&D 


Purpose: 

lb  compute  the  sensitrities  oe  design  dependent  loads  for  active  boundary  conditions. 

MAPOL  Calling  Sequence: 

CALL  DDLOAD  {  KDV ,  GSIZEB,  BC,  SMPLOD,  DDFLG,  [PEAS],  [DPVJ]  ); 

ndv  The  number  of  global  design  variables  (Integer,  Input) 

G3IZEB  The  size  of  the  structural  set  (Integer,  Input) 

bc  The  boundary  condition  identification  number  (Integer,  Input) 

smplod  Unstructured  entity  of  simple  load  vector  information  (Input) 

DDFLG  Design  dependent  load  flag:  (Integer,  Output) 

0  if  no  design  dependent  loads 
*  1  if  any  static  loads  are  design  dependent 

[PGAS]  Matrix  entity  containing  a  partitioning  vector  of  active  applied  static  load 

conditions  (Input) 

[DPVJ]  Matrix  entity  containing  the  senstivities  of  each  active  static  load  to  the 

design  variables  (Output) 

Application  Calling  Sequence: 

None 

Method: 

The  module  first  determines  if  there  are  any  static  loads  and  if  any  of  the  app!'Ctd  static  loads  are  potentially 
design  dependent.  This  is  done  by  reading  the  SMPLOD  entity  and  checking  if  any  gravity  or  thermal  loads 
are  defined.  If  any  design  dependent  applied  loads  are  found,  the  module  continues  by  reading  the 
remainder  of  the  first  smplod  record,  the  case  relation  for  all  statics  disciplines  in  the  current  active 
boundary  condition  and  all  the  LOAD  relational  tuples.  Finally,  the  PGA  vector  is  brought  into  core  to 
allow  the  active  loads  to  be  identified.  Once  all  the  data  are  in  core,  the  PGA  data  are  used  to  identify 
the  active  static  loads.  For  each  active  load,  the  case  relation  is  searched  to  determine  if  any  of  the 
simple  loads  comprising  the  current  active  load  are  design  dependent.  This  involves  the  LOAD  relational 
data  for  MECH  loads  since  the  LOAD  data  may  refer  to  GRAV  loads  which  are  design  dependent.  If  any 
design  dependent  loads  are  found,  their  sensitivities  are  computed  using  the  dfvrgi  and/or  DPTHGI 
matrix  entities  of  simple  load  sensitivities.  The  DPVJ  entity  is  loaded  as  active  design  dependent  loads 
are  encountered  with  care  taken  that  all  active  loads  (including  design  independent  loads)  are  accounted 
for  in  the  column  dimension  of  the  matrix  entity. 
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Design  Requirements; 

1.  This  module  must  be  called  to  initialize  the  DDE'LG  flag  that  is  used  by  the  MAPOL  sequence  to  direct 
subsequent  matrix  operations  relating  to  the  load  sensitivities  even  if  no  design  dependent  loads 
exist  in  the  boundary  condition. 

2.  The  module  assumes  that  at  least  one  active  static  applied  load  exists  in  the  current  boundary  condition. 
Error  Conditions: 

None 


Engineering  Application  Module:  DE S IGN 

Entry  Point:  DESIGN 

Purpose: 


lb  perform  redesign  by  math  programming  methods  based  on  the  current  set  of  active  constraints  and 
constraint  sensitivities. 


MAPOL  Calling  Sequence: 

CALL  DESIGN  (  NITER,  NDV,  APPCNVRG,  MOVLIM,  CNVRGLIM,  CTL,  CTLMIN,  NOMOPTBC , 
GLBDES ,  CONST,  [AMAT] ,  DESHIST  ); 


NITER 

NDV 

APPCNVRG 

MOVLIM 

CNVRGLIM 

CTL 

CTIMIN 

NDMOPTBC 

GLBDES 

CONST 

[AMAT] 

DESHIST 


Design  iteration  number  (Integer,  Input) 

The  number  of  design  variables  (Integer,  Input) 

The  approximate  problem  converge  flag  (Logical,  Output) 

=  FALSE  if  not  converged 

*=  TRUE  if  converged  in  objective  function  value 

Limit  on  how  much  a  design  variable  can  move  for  this  iteration  (Real,  Input) 
Tblerance  for  indicating  approximate  problem  convergence  (Real,  Input) 
Tblerance  for  indicating  an  active  constraint  (Real,  Output) 

Tblerance  for  indicating  a  violated  constraint  (Real,  Output) 

Number  of  optimization  boundary  conditions  (Integer,  Input) 

Relation  of  global  design  variables  (Character,  Input) 

Relation  of  constraint  values  (Character,  Input) 

Matrix  of  constraint  sensitivities  (Input) 

Relation  of  design  iteration  information  (Character,  Output) 


Application  Calling  Sequence: 

None 

Method: 

The  module  fl.st  brings  design  variable,  objective,  constraint,  objective  sensitivity  and  constraint 
sensitivity  information  into  core.  Calls  to  ADS  then  invoke  the  mathmatical  programming  algorithm 
which  performs  the  redesign  task.  Function  evaluations  and  gradient  evaluations  that  are  required  as 
part  of  the  math  programming  task  are  performed  by  subroutines  FEVAL  and  GREVAL,  respectively.  Once 
the  appoximate  optimizaton  process  is  complete,  the  GLBDES  relation  is  updated  with  the  new  values  of 
the  design  variables  and  a  new  entry  is  written  to  the  DESHIST  relation. 

Design  Requirements: 

1.  This  module  is  called  after  all  the  analysis  and  gradient  information  has  been  computed  for  a  design 
iteration.  It  is  therefore  the  last  module  within  the  design  iteration  loop. 

Error  Conditions: 

1.  The  module  does  not  have  sufficient  in-core  memory  available. 
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Engineering  Application  Module:  DESPUNCH 

Entry  Point:  DESPCH 

Purpose: 

Punchs  out  the  new  Bulk  Data  cards  with  property  values  representing  the  current  design  model.  The 
activation  of  this  module  depends  on  the  punch  input. 

MAPOL  Calling  Sequence: 

CALL  DESPUNCH  (  NITER,  PUNCH,  OLOCALDV  )  ; 

NITER  Current  design  iteration  number.  (Integer,  Input) 

PUNCH  Logical  flag  indicating  that  the  user  has  requested  the  new  model  be 

punched.  (Logical,  Input) 

olocaldv  Relation  of  current  local  design  variable  values.  (Input) 

Application  Calling  Sequence: 

None 

Method: 

This  module  works  in  conjunction  with  the  IFP  module  and  the  actcon  module.  IFP  stores  the  design 
invariant  bulk  data  and  the  design  variant  bulk  data  is  a  series  of  data  base  entities  that  are  read  here. 
The  actcon  module  actually  computes  the  current  local  design  variable  values  and  loads  them  in  the 
olocaldv  relation.  It  also  sets  the  PUNCH  logical  flag  if  punched  output  has  been  requested  for  the 
current  design  iteration. 

If  the  punch  flag  is  true,  the  data  in  the  OLOCALDV  relation  are  looped  over  and  the  new  property  and/or 
connectivity  bulk  data  entries  are  punched  to  the  ASTROS  punch  file. 

Design  Requirements: 

1.  IFP  must  have  been  called  to  store  the  bulk  data  deck  for  punch  requests. 

2.  actcon  must  have  been  called  during  the  current  iteration  to  load  the  OLOCALDV  relation. 

Error  Conditions: 

None 
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Engineering  Application  Module:  DMA 


Entry  Point:  DMA 


Purpose: 

lb  assemble  the  direct  and/or  modal  stiffness,  mass  and/or  damping  matrices  including  extra  point 
degrees  of  freedom  for  transient,  frequency  and  blast  disciplines. 

MAPOL  Calling  Sequence: 

CALL  DMA  (  NITER,  BC,  ESIZE(BC),  PSIZE(BC),  BSPDT(BC),  DSfiT(BC),  [MAA]  , 

[KAA]  ,  [THN(BC)],  [0SUBO (BC) ] ,  N6DR,  LAMBDA,  [PHIA],  [MDD] ,  [BDD] , 
[KDDT] ,  [KDDF] ,  [MHH] ,  [BBS] ,  [RHHT] ,  [KHHF] ) ; 


NITER 

BC 

ESIZE(BC) 

PSIZE (BC) 

BQPDT (BC) 
USET (BC) 
[MAA] 

[KAA] 
[TMN(BC)] 
[GSOBO  (BC)  ] 
NGDR 


LAMBDA. 


[PHIA] 

[HDD] 

[BDD] 

[KDDT] 

[KDDF] 

[MHH] 

[BHH] 

[KHBT] 


Design  iteration  number  (Integer,  Input) 

Boundary  condition  identification  number  (Integer,  Input) 

The  number  of  extra  point  degrees  of  freedom  in  the  boundary  condition 
(Integer,  Input) 

The  size  of  the  physical  set  for  the  current  boundary  condition. 

(Integer,  Input) 

Relation  of  basic  grid  point  coordinate  data  (Character,  Input) 

The  unstructured  entity  defining  structural  sets  (Character,  Input) 

Matrix  entity  containing  the  mass  matrix  in  the  analysis  set  (Input) 

Matrix  entity  containing  the  stiffness  matrix  in  the  analysis  set  (Input) 

Transformation  matrix  for  multipoint  constraints  (Input) 

Transformation  matrix  for  reduction  to  the  analysis  set  (Input) 

Denotes  dynamic  reduction  in  the  boundary  condition. 

=0  No  GDR 
=  -1  GDR  is  used 
(Input,  Integer) 

Relational  entity  containing  the  output  from  the  real  eigenanalysis 
(Input) 

Matrix  of  eigenvectors  from  the  real  eigenanalysis  in  the  analysis  set  (In¬ 
put) 

Direct  dynamic  mass  matrix  (Output) 

Direct  dynamic  damping  matrix  (Output) 

Direct  transient  stiffness  matrix  (Output) 

Direct  frequency  stiffness  matrix  (Output) 

Modal  dynamic  mass  matrix  (Output) 

Modal  dynamic  damping  matrix  (Output) 

Modal  transient  stiffness  matrix  (Output) 
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[KHBF] 


Modal  frequency/flutter  stiffness  matrix  (Output) 


Application  Calling  Sequence: 

None 

Method: 

The  module  begins  by  retrieving  all  the  case  tuples  for  TRANSIENT,  frequence  or  blast  disciplines 
for  the  current  boundary  condition.  If  any  dynamic  matrix  assembly  is  required,  the  BGPDT  data  is  also 
retrieved  and  the  number  of  extra  points  in  the  current  boundary  condition  is  determined  and  the  psize 
variable  set  to  be  the  size  of  the  physical  set.  Continuing  with  the  module  initialization,  the  DMAPVC 
submodule  is  called  to  generate  all  the  partitioning  vectors  for  the  dynamic  degrees  of  freedom  including 
the  extra  points.  If  there  are  extra  points,  the  module  proceeds  to  expand  the  analysis  set  structural 
matrices,  mode  shapes  and  transformation  matrices  to  include  the  extra  point  degrees  of  freedom.  This 
is  done  in  the  dmaexp  submodule. 

Next,  the  DMAX2  submodule  is  called  to  assemble  any  direct  matrix  input.  These  include  M2PP,  B2PP 
and  K2PP  inputs  as  well  as  transfer  function  data.  The  DMAX2  submodule  forms  the  zeroth,  first  and 
second  order  inputs  in  the  direct  dynamic  degrees  of  freedom.  The  modal  form  is  obtained  during  the 
actual  dynamic  matrix  assembly. 

The  module  then  proceeds  to  obtain  the  information  needed  to  assemble  the  damping  matrix.  The 
damping  attribute  of  the  case  relation  is  checked  and  the  vsdamp  and  TABOMP  entries  are  searched  for 
a  matching  identification  number.  Logical  flags  are  set  to  indicate  that  damping,  modal  damping  and/or 
direct  damping  are  to  be  used.  If  modal  damping  is  selected,  the  LAMBDA  relation  is  read  to  obtain  the 
natural  frequencies  for  the  computed  modes.  As  a  final  initialization  task,  the  DMA  module  prepares  the 
data  needed  to  generate  the  d-sized  hidden  matrix  entity  icmatrix  used  to  perform  direct  transient 
analysis.  The  ICDATA  information  is  brought  into  open  core  and  the  psized  scratch  matrix  to  be  reduced 
to  icmatrix  is  created. 

Once  these  initialization  tasks  have  been  completed,  the  loop  to  form  the  direct  and/or  modal  dynamic 
matrices  begins.  The  case  relation  tuples  for  the  dynamic  disciplines  are  searched  sequentially  and  the 
requisite  matrices  formed.  Note  that  the  restrictions  in  the  definition  of  a  boundary  condition  make  it 
such  that  only  one  form  of  each  matrix  is  possible.  The  DMA  module  forms  up  to  eight  matrices:  [MDD] , 
[BDD] ,  [KDDF],  [MHH] ,  [BHH] ,  [XDDT] ,  [KHHF]  ,  and  [KHHT] 

depending  on  the  requested  disciplines  and  discipline  options.  The  info  arrays  for  the  matrices  are  used 
to  store  flags  denoting  coupled  or  uncoupled  matrices  and  the  form  of  the  damping  used  in  the  modal 
stiffness  and/or  damping  matrices.  When  all  the  case  tuples  have  been  searched  and  the  required 
dynamic  matrices  formed,  the  module  begins  the  cleanup.  The  first  task  is  to  complete  the  generation 
of  the  initial  conditions  matrix  by  reducing  the  scratch  p-sized  matrix  to  the  direct  dynamic  set. 
Following  this  action,  the  other  scratch  matrices  used  in  the  module  are  destroyed  and  control  returned 
to  the  executive. 

Design  Requirements: 

1.  The  pfbdlk  and  modules  must  have  been  called  to  perform  the  preprocessing  for  the  initial 
conditions,  transfer  functions,  and  direct  matrix  input. 

Error  Conditions: 

None 
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Engineering  Application  Module:  DYNLOAD 
Entry  Point:  DYNLOD 


Purpose: 

lb  assemble  the  direct  and/or  modal  time  and/or  frequency  dependent  loads  including  extra  point  degrees 
of  freedom  for  dynamic  response  disciplines. 

MAPOL  Calling  Sequence: 

CALL  DmLOAD  (  NITER,  BC,  GSIZE,  ESIZE(BC),  PSIZE (BC) ,  SMPLOD,  BGPDT(BC) , 

USET(BC) ,  [TMN(BC) ] ,  [GSUBO(BC) ] ,  NGDR,  [PB1A] ,  [QHJL] ,  [PDT] , 
[PDF] ,  [PTGLOAD] ,  [PTH LOAD] ,  [PFGLCAD] ,  [PFHLOAD]  ) ; 


NITER 

BC 

GSIZE 
ESIZE  (BC) 

PSIZE (BC) 

SMPLOD 
BGPDT (BC) 
USET (BC) 
[IME?  (BC)  ] 
[GSUBO (BC) ] 
NGDR 


[PHI  A] 

[QHJL] 

[PDT] 

[PDF] 

[PTGLOAD] 

[PTHLOAD] 

[PFGLOAD] 

[PFHLOAD] 


Design  iteration  number  (Integer,  Input) 

Current  boundary  condition  number  (Integer,  Input) 

Length  of  the  g-set  vector  (Integer,  Input) 

The  number  of  extra  point  degrees  of  freedom  in  the  boundary  condition 
(Integer,  Input) 

The  size  of  the  physical  set  for  the  current  boundary  condition. 

(Integer,  Input) 

Unstructured  entity  of  simple  load  vector  information  (Input) 

Relation  of  basic  grid  point  coordinate  data  (Input) 

The  unstructured  entity  defining  structural  sets  (Input) 

Matrix  for  reducing  MPCs  (Input) 

Matrix  for  reducing  omitted  DOF  (Input) 

Denotes  dynamic  reduction  in  the  boundary  condition. 

=0  No  GDR 
=  -1  GDR  is  used 
(Input,  Integer) 

Natural  modes  matrix  in  the  a-set  (Input) 

Aerodynamic  matrix  for  gust  (Input) 

Dynamic  load  vector  for  transient  analysis  (Input) 

Dynamic  load  vector  for  frequency  analysis  (Input) 

Applied  load  matrix  for  the  time  dependent  loads  when  load  print  is  re¬ 
quested  (Character,  Output) 

Applied  load  matrix  for  the  time  dependent  loads  when  MODAL  GUST  print 
is  requested  (Character,  Output) 

Applied  load  matrix  for  the  frequency  dependent  loads  when  LOAD  print 
is  requested  (Character,  Output) 

Applied  load  matrix  for  the  frequency  dependent  loads  when  MODAL  GUST 
print  is  requested  (Character,  Output) 
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Application  Calling  Sequence: 

None 

Method: 

The  module  first  interrogates  lbs  CMS  relation  to  see  whether  any  dynamic  analyses  are  to  be  performed 
for  the  current  boundary  condition.  If  not,  the  module  terminates.  Error  checking  is  performed  to  make 
sure  legal  requests  have  been  made  and  bookkeeping  is  performed  fcc  set  up  for  matrix  reductions  and 
extra  points.  Call{e)  are  then  made  tc  DM&PS  to  generate  the  applied  loads  in  th8  p-set.  EMAP6  induces 
these  loads  to  the  d-or  h-sei,  depending  on  the  approach.  Separate  routines  generate  loads  in  the 
frequency  &nd  time  domains. 

Design  Requirements: 

1.  Follows  computation  of  quantities  in  the  a-set.  If  the  MODAL  approach  is  being  used,  the  t*atural  mode 
shapes  must  be  computed. 

Error  Conditions: 


1.  No  more  than  one  frequency  and/or  transient  load  is  allowed  pe?  boundary  condition. 


Engineering  Application  Module:  DYNRBP 


Sntry  Point:  DYNBSP 


Purpose: 

lb  compute  the  direct  or  modal  displacements,  velocities  and  accelerations  for  transient  and  frequency 
analyses. 

MAPOL  Calling  Sequence: 

CAX&  OXNRSF  <  BC,  B3XZ£(SC),  [MDD]  ,  [BOD],  [HDD*]  ,  [KDDF] ,  [MHG]  ,  [BHB]  , 

[REST]  ,  [KKEF]  ,  [FD'S]  ,  [PDF]  ,  [QHHLj  ,  [tTFRSMA]  ,  [DFSBQA]  , 

[OTSSMI]  ,  [TJFRSGI]  ,  [OTRANE]  ,  [DFRHQE]  )  ; 


BC 

XSIZE(BC) 

:i«dd] 

[SDD] 

[roDTJ 

[KDD  Fj 

[MHK] 

[BHB] 

[KH3T] 

[KHHF] 

[PDT] 

[PDF] 

[GHHI/j 

[tFTBaa&] 

[DFKBQA] 

[CTRaNI] 

[UFSESI] 

[U5SSHE] 

[tJFSSQEj 


Number  of  the  current  boundary  condition  (Integer,  Input) 

The  number  of  extra  point  degrees  of  freedom  in  the  boundary  condition 
(Integer,  Input) 

Mass  matrix  in  the  d-set  (Input) 

Damping  matrix  in  the  d-set  (Input) 

Stiffness  matrix  in  the  d-set  for  transient  analyses  (Input) 

Stiffness  matrix  in  the  d-set  for  frequency  analyses  (Input) 

Modal  mass  matrix  (Input) 

Medal  damping  matrix  (Input] 

Modal  stiffness  matrix  for  transient  analyses  (Input) 

Modal  stiffness  matrix  for  frequency  analyses  (Input) 

Matrix  of  applied  loads  for  transient  analysis  (Input) 

Matrix  of  applied  loads  for  transient  analysis  (Input) 

Generalised  aerodynamic  forces  for  gust  analyses  (Input) 

Transient  response  vectors  in  the  a-set  (Output) 

Frequency  response  vectors  in  the  a-set  (Output) 

Transient  response  vectors  in  the  i-set  (Output) 

Frequency  response  vectors  in  the  i-set  (Output) 

Transient  response  vectors  in  the  e-set  (Output) 

Frequency  response  vectors  in  the  e-set  (Output) 


Application  Calling  Sequence: 
None 


I 
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Method: 


The  module  first  interrogates  the  cask  relation  to  see  whether  any  dynamic  analyses  are  to  be  performed 
for  the  current  boundary  condition.  If  not,  the  module  terminates.  Bookkeeping  is  performed  to  set  up 
for  any  gust  analyses  and  to  process  extra  points.  A  loop  on  the  number  of  cases  with  dynamic  response 
requirements  for  the  current  boundary  condition  is  then  made.  Time  or  frequency  points  at  which  the 
response  is  required  are  established  and  the  required  analyses  are  performed.  Separate  subroutines 
control  the  performance  of  requested  analyses: 


ROUTINES 

PURPOSE 

TRUNCS/D 

Uncoupled  transient  analysis 

TRCOUP 

Coupled  transient  analysis 

FRUHCS/D 

Uncoupled  frequency  analysis 

FRCOUP 

Coupled  frequency  analysis 

FRSUST 

Frequency  response  with  gust 

These  routines  fill  output  vectors  with  response  quantities  (displacement,  velocity  and  acceleration).  If 
there  are  extra  points,  a  partitioning  operation  is  performed  to  segregate  extra  point  data  into  separate 
matrix  entities. 

Design  Requirements: 

1.  Modules  EMA  and  DYNLOAD  prepars  matrix  quantities  that  are  required  for  this  module.  If  a  gust 
analysis  is  being  performed,  module  QHHLGKN  must  have  been  processed  as  well. 

Error  Conditions: 

None 
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Engineering  Application  Module:  EDR 
Entry  Point:  EDRDRV 


Purpose: 

Tb  compute  the  stresses,  strains,  grid  point  forces  and  strain  energies  for  elements  selected  for  output 
for  the  particular  boundary  condition. 

MAPOL  Calling  Sequence: 

CALL  EDR  (  NUMOPTBC,  BC,  NITER,  NDV,  QSIZE,  EOSUMMR2T,  EODISC,  GLBDES, 

LOCLVAR,  [PTRANS] ,  [US(BC) ] ,  [OAQ  (BC) ] ,  [blug] ,  [UTRANG] , 

[UFREQG],  [PHIG (BC) ] ,  [PHIGB(BC)]  ); 


NUMOPTBC 

BC 

NITER 

NDV 

GSIZE 

EOSUMMRT 

EODISC 


GLBDES 

LOCLVAR 

[PTRANS] 
[UG(BC) ] 
[UAG(BC)  ] 
[BLDG] 

[UTRANG] 

[UFREQG] 

[PHIG(BC) ] 

[PHIGB (BC) ] 


Number  of  optimization  boundary  conditions  (Integer,  Input) 

Boundary  condition  identification  number  (Integer,  Input) 

Iteration  number  for  the  current  design  iteration  (Integer,  Input) 

The  number  of  global  design  variables  (Integer,  Input) 

The  size  of  the  structural  set  (Integer,  Input) 

Relation  containing  the  summary  of  elements,  design  iterations  and 
boundary  conditions  for  which  output  is  desired  (Input) 

Unstructured  entity  referred  to  by  eosummry  containing  the  disciplines 
for  which  output  is  required  for  each  element/iteration/boundary  condi¬ 
tion  (Input) 

Relation  of  global  design  variables  (Character,  Input) 

Relation  containing  the  relationship  between  local  variables  and  global 
variables  in  the  design  problem  (Character,  Input) 

The  design  variable  linking  matrix  (Character,  Input) 

Matrix  of  global  displacements  from  statics  analyses  (Input) 

Matrix  of  global  displacements  from  saero  analyses  (Input) 

Matrix  of  global  displacements/velocities/accelerations  for  BLAST  re¬ 
sponse  analyses  (Input) 

Matrix  of  global  displacements/velocities/accelerations  for  TRANSIENT  re¬ 
sponse  analyses  (Input) 

Matrix  of  global  displacements/velocities/accelerations  for  FREQUENCE  re¬ 
sponse  analyses  (Input) 

Matrix  of  global  eigenvectors  from  real  eigenanalysis  for  MODES  analyses 
(Input) 

Matrix  of  global  eigenvectors  for  BUCKLING  analyses  (Input) 
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Application  Calling  Sequence: 

None 

Method: 

The  EOSOMMRY  relation  is  opened  and  read  for  the  current  boundary  condition.  If  any  element  output 
requests  exist,  processing  continues  by  loading  the  input  matrices  associated  with  the  discipline 
dependent  displacement  fields  into  an  character  array  such  that  the  order  in  which  disciplines  are 
processed  correspond  to  the  order  of  the  matrices.  Following  this,  there  is  a  section  of  code  set  aside  for 
discipline  dependent  processing.  Currently,  two  tasks  are  performed: 

(1)  The  number  of  mode  shapes  computed  in  the  real  eigenanalysis  (if  one  was  performed)  is  determined 
by  opening  the  phig  matrix;  and  (2)  any  thermal  load  set  ID’s  in  the  CASE  relation  are  replaced  by  the 
record  number  in  gridtemp  that  corresponds  to  the  applied  load  case. 

The  initialization  tasks  continue  with  a  call  to  the  PRELDV  utility  to  set  up  for  computation  of  the  local 
design  variables  associated  with  designed  elements.  The  transformation  matrices  and  material  proper¬ 
ties  are  also  prepared  for  fast  retrieval  by  the  element  routines.  The  gpfdata  relation  is  opened  for 
output  and  the  EODISC  data  is  read  into  memory.  At  this  point,  the  EODISC  record  number  in  the 
EOSUMMRY  data  is  replaced  by  the  open  core  pointer  where  the  record  begins  in  memory.  With  the 
initialization  complete,  the  EDR  module  proceeds  to  compute  the  desired  element  response  quantities 
for  all  the  "subcases"  (considered  by  EDR  to  be  represented  by  a  single  displacement  vector)  for  any  or 
all  disciplines  that  have  been  analyzed  in  the  current  boundary  condition.  The  computation  occurs  in 
the  following  three  steps: 

(1)  Determine  the  set  of  disciplines  and  subcases  for  which  any  element  response  quantities  are 
needed 

(2)  Read  into  open  core  as  many  displacement  vectors  (real  and/or  complex)  as  will  fit 

(3)  Call  element  dependent  routines  to  compute  the  stress,  strain  strain  energy,  forces  and  grid 
point  forces  for  each  displacement  vector 

To  perform  step  (1),  the  eosommry  data  is  read  for  each  discipline  and  the  corresponding  EODISC  data 
is  used  to  form  a  unique  list  of  subcases  for  each  discipline  in  the  current  boundary  condition.  A  list  of 
the  form: 

SDISC, (DISC  TYPE (I) ,NSUBCASE , SUBCASE  ID(J) , J«1 ,NSOBCASE) ,I«1,NDISC) 

These  data  are  sorted  by  discipline  type  in  the  order  defined  in  the  /EDRDIS/  common  block  and  by  the 
subcase  "identification  numbers"  within  each  discipline.  The  subcase  ID’s  refer  to  the  column  number 
in  the  displacement  matrix  for  the  discipline.  For  statics  and  modes,  these  numbers  are  incremented  by 
one  for  each  new  load  condition  or  eigenvector  while  transient,  frequency  and  blast  results  use  an 
increment  of  three  to  accommodate  the  velocity  and  accelerations  that  are  stored  in  the  same  matrix. 
After  this  in-core  list  has  been  formed,  it  is  read  to  determine  which  displacement  vectors  are  to  be 
brought  into  open  core.  The  module  determines  the  amount  of  remaining  memory  and  brings  as  many 
displacement  vectors  into  memory  as  possible.  The  terms  are  converted  to  single  precision  at  this  point. 
Once  all  the  displacements  are  in  memory,  or  memory  is  full,  the  element  dependent  routines  are  called. 
Within  each  element  dependent  routine,  the  geometrical  portion  of  the  element  processing  is  performed 
once  followed  by  a  loop  over  all  incore  displacements  to  compute  the  element  response  quantities.  For 
each  displacement  set,  all  the  element  response  quantities  including  grid  point  forces,  stresses,  strains, 
strain  energies  and  element  forces  are  computed  and  stored  on  the  EOjoooc  element  response  quantity 
relations.  Note  that  the  exact  quantities  requested  by  the  user  are  not  used  at  this  point,  but  will  only 
be  used  to  determine  which  data  to  print.  Once  all  the  elements  have  been  processed,  the  module  loops 
back  for  any  remaining  displacement  vectors  and,  when  all  of  these  are  processed,  terminates. 
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Design  Requirements: 


1.  The  PFBtJLK  processing  of  the  element  output  requests  must  have  been  completed  and  be  compatible 
with  the  data  currently  resident  in  the  CA3E  relation. 

2.  The  module  may  be  called  when  no  element  output  requests  exist  in  the  Solution  Control. 

Error  Conditions: 

None 


125 


Engineering  Application  Module: 

Entry  Point:  EMA1 


EMA1 


Purpose: 

Tb  assemble  the  element  stiffness  and  mass  matrices  (stored  in  the  KEIM  and  HELM  entities)  into  the 
design  sensitivity  matrices  dkvi  and  DMVI. 

MAPOL  Calling  Sequence: 

CALL  EMAl  (  NDV,  GLBDES,  DVCT,  XELM,  MELM,  GMKCT,  DKVI,  GMMCT,  DMVI  ); 

ndv  Number  of  design  variables  (Integer, Input) 

GLBDES  Relation  of  global  design  variables  (Character,  Input) 

DVCT  Relation  containing  the  data  required  for  the  assembly  of  the  design  sensi¬ 

tivity  matrices  (Character,  Input) 

KELM  Unstructured  entity  containing  the  element  stiffness  matrix  partitions 

(Character,  Input) 

meim  Unstructured  entity  containing  the  element  mass  matrix  partitions 

(Character,  Input) 

GMKCT  Relation  containing  connectivity  data  for  the  dkvi  sensitivity  matrix 

(Output) 

dkvi  Unstructured  entity  containing  the  stiffness  design  sensitivity  matrix  in 

a  highly  compressed  format  (Output) 

GMMCT  Relation  containing  connectivity  data  for  the  DMVI  sensitivity  matrix 

(Output) 

DMVI  Unstructured  entity  containing  the  mass  design  sensitivity  matrix  in  a 

highly  compressed  format  (Output) 

Application  Calling  Sequence: 

None 

Method: 

The  module  is  executed  in  two  passes;  once  for  stiffness  matrices  and  a  second  time  for  mass  matrices. 
In  the  first  pass,  DVCT  information  is  read  into  core  one  record  at  a  time.  The  algorithm  is  structured  to 
maximize  the  amount  of  processing  done  on  a  given  design  sensitivity  matrix  (typically  all  of  it)  in  core. 
Spill  logic  is  in  place  if  a  matrix  cannot  be  completely  held  in  core.  For  the  assembly,  subroutine  RQCOR1 
performs  bookkeeping  tasks  to  expedite  the  assembly  and  to  determine  whether  spill  will  be  necessary. 
Subroutine  ASSEM1  retrieves  kelm  information,  performs  the  actual  assembly  operations  and  places  the 
results  into  the  GMKCT  and  dkvi  entities.  When  the  DVCT  data  have  been  exhausted  a  check  is  made  as 
to  whether  mass  assembly  is  required.  If  a  discipline  which  requires  a  mass  matrix  is  included  in  the 
solution  control,  the  mass  terms  are  assembled  in  the  second  pass.  If  there  are  optimize  boundary 
conditions,  this  module  calculates  the  sensitivity  of  the  objective  to  the  design  variables  regardless  of 
whether  the  DMVI  matrices  are  required.  If  no  mass  information  is  required,  control  is  returned  to  the 
executive  and  the  second  pass  through  the  module  is  not  made.  For  the  second  pass,  MEIM  data  are  used 
and  the  dobj  attribute  is  added  to  the  GLBDES  entity,  if  required.  The  structure  of  the  assembly  operation 
is  otherwise  much  the  same  and  GM-5CT  and  DMVI  data  are  computed  and  stored. 
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Design  Requirements: 

1.  This  assembly  operation  follows  the  hakest  and  emg  modules. 

2.  Since  gravity  loads  require  BMVI  data,  it  is  necessary  to  perform  EMA1  prior  to  calling  LODGEN.  EMA1 
must  always  be  called  before  EMA2 . 

Error  Conditions: 

None 
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Engineering  Application  Module:  EMA2 

Entry  Point:  EMA2 

Purpose: 

lb  assemble  the  element  stiffness  and  mass  matrix  sensitivities  (stored  in  the  dkvt  and  DMVI  entities) 


into  the  global  stiffness  and  mass  matrices  for  the  current  design  iteration. 

MAPOL  Calling  Sequence: 

CALL  EMA2  (  MITER, 
DMVI , 

NDV,  GSIZEB,  GLBDES ,  GMKCT,  DKVI,  [K1GG] ,  Gt«CT, 

[MlGG]  )  ; 

NITER 

Design  iteration  number  (Integer,  Input) 

NDV 

The  number  of  design  variables  (Integer,  Input) 

G3IZEB 

Length  of  the  g-set  vectors  (Integer,  Input) 

GLKDES 

Relation  of  global  design  variables  (Character,  Input) 

GMKCT 

Relation  containing  connectivity  data  for  the  DKVI  sensitivity  matrix 
(Character,  Input) 

DKVI 

Unstructured  entity  containing  the  stiffness  design  sensitivity  matrix  in 
a  highly  compressed  format  (Character,  Input) 

[K1GG] 

Assembled  stiffness  matrix  in  the  g-set  (Output) 

GMMCT 

Relation  containing  connectivity  data  for  the  DMVI  sensitivity  matrix 
(Character,  Input, 

DMVI 

Unstructured  entity  containing  the  mass  design  sensitivity  matrix  in  a 
highly  compressed  format  (Character,  Input) 

[M1GG] 

Assembled  mass  matrix  in  the  g-set  (Output) 

Application  Calling  Sequence: 

None 

Method: 

The  structure  of  this  module  resembles  that  of  EMAl  and  is  also  executed  in  two  passes.  In  the  first  pass, 
GMKCT  information  is  read  into  core  one  record  at  a  time.  The  algorithm  is  structured  to  maximize  the 
number  of  columns  of  the  global  stiffness  matrix  that  are  assembled  at  one  time.  Spill  logic  is  in  place 
if  all  the  columns  cannot  be  assembled  at  once.  For  the  assembly,  subroutine  RQC0B2  performs 
bookkeeping  tasks  to  expedite  the  assembly  and  to  determine  whether  spill  will  be  necessary.  Subroutine 
ASSEM2  retrieves  the  DKVI  information,  performs  the  assembly  in  core  using  the  current  values  of  the 
design  variables,  and  stores  the  data  into  kgg.  When  the  gmkct  data  have  been  exhausted  a  check  is 
performed  as  to  whether  mass  assembly  is  required.  Flags  were  written  by  on  the  INFO  array  of 
the  DKVI  entity  to  indicate  whether  mass  assembly  is  required.  If  no  mass  information  is  required, 
control  is  returned  to  the  executive;  if  it  is,  the  second  pass  through  the  module  takes  place.  For  the 
second  pass,  DMVI  and  gmmct  data  are  used  to  generate  the  MGG  matrix.  The  structure  of  the  assembly 
operation  is  otherwise  much  the  same  and  the  mgg  matrix  is  computed  and  stored. 
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Design  Requirements: 

1.  For  OPTIMIZE  boundary  conditions,  EMA2  is  the  first  module  called  in  the  iteration  loop  and  precedes 
the  optimization  boundary  condition  loop.  For  ANALYZE  boundary  conditions,  the  module  immediately 
precedes  the  loop  on  analyze  boundary  conditions  and  the  NITER  argument  is  not  required.  In  both  cases, 
EMA2  must  always  follow  emai. 

2.  NITER  must  be  nonzero  for  optimization  boundary  conditions. 

Error  Conditions: 

None 
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Engineering  Application  Module:  EMG 
Entry  Point:  EMG 


Purpose: 

lb  compute  the  element  stiffness,  mass,  thermal  load  and  stress  component,  sensitivities  for  all  structural 
elements. 


MAPOL  Calling  Sequence: 

CALL  EMG  (  NDV,  GSIZEB,  GLBDES ,  DESLINK,  [SM&T]  ,  DVCT,  DVSIZE,  K2IM,  MELM, 
TEIM,  TKEF  )  ; 


NDV 

The  number  of  design  variables  (Integer,  Input) 

GSIZEB 

The  size  of  the  structural  set  (Integer,  Input) 

GLBDES 

Relation  of  global  design  variables  (Character,  Input) 

DESLINK 

Relation,  of  design  variable  connectivity  from  MAKEST  module  containing 
one  record  for  each  global  design  variable  connected  to  each  local  vari¬ 
able.  (Character,  Input) 

[SMAT] 

Matrix  entity  containing  the  sensitivity  of  the  stress  and  strain  compo¬ 
nents  to  the  global  displacements  (Character,  Output) 

DVCT 

Relation  containing  the  data  required  for  the  assembly  of  the  design  sensi¬ 
tivity  matrices  (Character,  Output) 

DVSIZE 

Unstructured  entity  containing  memory  allocation  information  on  the 

DVCT  relation  (Character,  Output) 

KELM 

Unstructured  entity  containing  the  element  stiffness  matrix  partitions 
(Character,  Output) 

MEIM 

Unstructured  entity  containing  the  element  mass  matrix  partitions 
(Character,  Output) 

TELM 

Unstructured  entity  containing  the  element  thermal  load  partitions 
(Character,  Output) 

TKEF 

Unstructured  entity  containing  the  element  reference  temperatures 
(Character,  Output) 

Application  Calling  Sequence: 

None 

Method: 

The  EMG  module  performs  the  second  phase  of  the  structural  element  preface  operations  with  theMRKEST 

module  performing  the  first  phase.  As  a  result,  these  two  modules  are  very  closely  related.  The  first 
action  of  the  EMG  module  is  to  determine  if  design  variables  and/or  thermal  loads  are  defined  in  the  bulk 
data.  If  they  are,  the  special  actions  for  design  variable  linking  and  thermal  stress  corrections  are  taken 
in  the  element  dependent  routines.  The  premat  utility  to  set  up  the  material  property  data  also  returns 
the  scon  logical  flag  to  denote  that  there  are  stress  constraints  defined  in  the  bulk  data.  The 
initialization  of  the  module  continues  with  the  retrieval  of  the  MFORM  data  to  select  lumped  or  coupled 
mass  matrices  in  the  elements  that  support  both  forms.  The  default  is  lumped  although  any  MFORM/ COU¬ 
PLED  (even  if  MFOHM/  lumped  also  exists )  will  cause  the  coupled  form  to  be  used.  If  thermal  loads  exist, 
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the  module  prepares  the  TREE  entity  to  be  written  by  the  element  dependent  routines.  If  the  design 
logical  is  set,  the  scrdes  scratch  entity  from  makest  is  opened  and  read  into  memory.  The  entity  is  then 
destroyed.  The  GLBDES  relation  is  opened  and  the  design  variable  identification  numbers  are  read  into 
memory.  Finally,  the  DVCT  entity  is  opened  and  flushed  and  memory  is  retrieved  to  be  used  in  the  DVCTLD 
submodule  to  load  the  DVCT  relation.  The  module  then  calls  each  element  dependent  routine  in  turn. 
The  order  in  which  these  submodules  are  called  is  very  important  in  that  it  provides  an  implicit  order 
for  the  MAKEST,  emg,  SCEVAL,  EDR  and  OFP  modules.  That  order  is  alphabetical  by  connectivity  bulk 
data  entry  and  results  in  the  following  sequence: 

(1)  Bar  elements 

(2)  Scalar  spring  elements 

(3)  Linear  isoparametric  hi  tahedral  elements 

(4)  Quadratic  isoparametric  hexahedral  elements 

(5)  Cubic  isoparametric  hexahedral  elements 

(6)  Scalar  mass  elements 

(7)  General  concentrated  mass  elements 

(8)  Rigid  body  form  of  the  concentrated  mass  elements 

(9)  Isoparametric  quadrilateral  membrane  elements 

(10)  Quadrilateral  bending  plate  elements 

(11)  Rod  elements 

(12)  Shear  panels 

(13)  Triangular  bending  plate  elements 

(14)  Triangular  membrane  elements 

Within  each  element  dependent  routine,  the  xxxEST  relation  for  the  element  is  opened  and  read  one 
tuple  at  a  time.  If  the  EST  relation  indicates  that  the  element  is  designed,  the  scrdes  data  is  used  to 
write  one  set  of  tuples  to  the  DVCT  relation  for  each  unique  design  variable  linked  to  the  element.  The 
set  of  tuples  consists  of  one  row  for  each  node  to  which  the  element  is  connected.  If  the  element  is  not 
designed,  a  single  set  of  tuples  is  written  connected  to  the  "zeroth"  (implicit)  design  variable.  The  element 
dependent  geometry  processor  is  then  called  to  generate  the  KELM,  meim  and  TEIM  entries  for  the 
element.  These  data  must  be  generated  before  the  next  call  to  DVCTLD  since  the  DVCT  forms  the  directory 
to  all  three  of  these  entities.  Once  all  the  elements  are  processed  within  the  current  element  dependent 
routine,  the  TREE  entity  is  appended  with  the  vector  of  reference  temperatures  for  the  current  set  of 
elements.  Again,  the  order  of  these  reference  temperatures  are  determined  by  the  sequence  listed  above 
and  is  assumed  to  hold  in  other  modules.  When  all  the  element  dependent  drivers  have  been  called  by 
the  EM3  module  driver,  clean  up  operations  begin.  The  entities  that  have  been  open  for  writing  by  the 
element  routines  are  closed,  the  remaining  in-core  DVCT  tuples  are  written  to  the  data  base  and  the 
dvct  relation  is  sorted.  If  there  are  design  variables,  the  DVCT  is  sorted  on  the  dvid  attribute  and, 
within  each  unique  DVID,  by  KSIL.  If  there  are  no  design  variables  (all  dvid’s  are  zero),  the  dvct  is 
sorted  only  on  ksil.  Finally,  if  stress  or  strain  constraints  were  defined  in  the  bulk  data  stream,  the 
SMAT  matrix  of  constraint  sensitivities  to  the  displacements  is  closed.  SMAT  was  opened  by  the  PREMAT 
module  when  the  SCON  constraint  flag  was  set. 
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Design  Requirements: 

1.  The  MAKES?  module  must  have  been  called  prior  to  the  ems  module. 

Error  Conditions: 

1.  Illegal  element  geometries  and  nonexistent  material  properties  are  flagged. 
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Engineering  Application  Module:  FCEVAL 
Entry  Point:  FCEVAL 


Purpose: 

%  evaluate  the  current  value  of  all  frequency  constraints. 
MAFOL  Calling1  Ssouence: 

CALL  FCEVAL  ^  NIT5SR,  BC,  LAMBDA,  CONST  ) ; 


111  TER 
BC 

LAMBDA 

CONST 


Design  iteration  number  (Integer,  Input) 

Boundary  condition  identification  number  (Integer,  Input) 

Relational  entity  containing  the  output  from  the  real  eigenanalysis 
(Input) 

Relation  of  design  constraint  values  (Character,  Output) 


Application  Calling  Sequence: 
None 


Method: 

The  FCEVAL  module  first  determines  if  any  frequency  constraints  are  applied  to  the  modal  analysis  in 
the  current  boundary  condition.  If  any  constraints  are  applle  3  to  the  modal  analysis,  the  module  proceeds 
to  open  the  dconfrq  relation  to  obtain  the  applied  constraints  and  the  lwmbda  relation  to  obtain  the 
computed  frequencies.  The  final  initialisation  task  is  to  open  the  const  relation  to  store  the  computed 
frequency  constraints.  The  actus'  computation  involves  looping  throught  the  DCONFRp.  'elation  for  the 
current  frequency  constraint  set  and  conditioning  the  lambda  relation  to  retrieve  the  results  for  the 
modes  that  are  constrained.  Having  retrieved  the  mode  number  and  the  computed  modal  frequency  from 
Lambda,  the  applied  upper  or  lower  hound  constraint  is  computed  and  stored  cn  the  CONST  -elation. 

Design  Requirements: 

1.  The  FCEVAL  modulo  assumes  that  the  current  boundary  conditio  i  is  an  optimization  boundary 
condition. 


Error  Conditions: 

1.  The  frequency  constraint  set  referenced  by  Solution  Control  does  not  exist  in  the  DCONFRQ  relation. 

2.  The  frequency  or  eigenvector  for  the  constrained  mode  was  not  extracted  in  the  rea1  eigenana’yeis. 

3.  The  constrained  mode  is  a  rigid  body  mods  (zero  frequency)  and  therefore  cannot  be  constrained. 


133 


Engineering  Application  Module:  flcttdma 


Entry  Point:  FLTDMA. 

Purpose: 

Assembles  the  dynamic  matrices  for  the  flutter  disciplines. 

MAFQL  Calling  Sequence: 

CA&B  FIXFTDM A  (  NITER,  SC,  SUB,  ESIZE(BC),  P3I?4E(BC)  ,  EGPDT(BC),  USST(BC), 
[KAA]  f  [KAA],  [TMN(BC)J;  [GSUBO  (BC)  ]  ,  BGDR,  LAMBDA,  [PHIA], 
[MHHFL  'BC ,  SUB)  ]  ,  [BHH5T,  (BC ,  SUB)  ]  ,  [KH53ST  (BC ,  SUB)  ]  )  ; 


NIT3R  Design  iteration  number.  (Integer,  Input) 

BC  Boundary  condition  number.  (Integer,  Input) 


SUB 


Flutter  su?:<case  number.  (Integer,  Input) 


SS2J5F=(BC) 
PSISE (BC) 
BSPD-r  (BC) 
D$£T (BC) 
CiSftAI 


Number  of  extra  points  for  the  current  boundary  condition.  (Integer,  In¬ 
put) 

Number  of  physical  degrees  of  freedom  in  the  currant  boundary  condi¬ 
tions  (G5XZE+ESIZE)  (Integer,  Input) 

Current  boundary  condition’s  relation  of  basic  grid  point  data  (expanded 
to  include  extra  points  and  any  GDR  scalar  points)  (Input) 

Current  boundary  condition’s  unstructured  entity  of  set  definition  masks 
(expanded  to  include  extra  points  and  any  GDR  scalar  points)  (Input) 

Mats  matrix  in  the  analysis  set.  (Input) 


[K3LA] 


Stiffness  matrix  in  the  analysis  sot.  (Input) 


[TMK(BC)} 

[eaoao  cbc) ] 

NGOR 

LkMBDA 

[PHIA] 

[BfeSFL  (BC ,  SUB)  ] 

[BHHPL  (BC ,  SUB)  ] 


Multipoint  constraint  transformation  matrix  for  the  current  boundary 
condHion.  (Input) 

Static  condensation  or  GDR  reduction  matrix  for  the  current  boundary  con¬ 
dition,  (Input) 

Denotes  dynamic  reduction  in  the  boundary  condition. 

*  0  Nc-  GDR 
~  -1  GDR  is  used 
(Input,  Integer) 

Relation  of  normal  mode  eigenvalues  output  from  the  REIG  module. 
(Input) 

Matrix  of  normal  mode  eigenvectors  in  the  analysis  set  output  from  reig. 
(Input) 

Generalized  mass  matrix  for  the  current  flutter  subcase  in  the  h-set 
(normal  modes+extra  points)  including  any  transfer  functions  and  M2PP 
input.  (Output) 

Generalized  damping  matrix  for  the  current  flutter  subcase  in  the  h-set 
(normal  modes+extra  points)  including  any  transfer  functions,  B2PP  in¬ 
put  and  VSDAMP  input.  (Output) 


s 
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[KHHFL  (sc ,  SOB)  ]  Generalized  stiffness  matrix  for  the  current  Hatter  subca30  in  flie  h-set 

(normal  modes+extra  points)  including  any  transfer  functions  K2PP  input 
and  VSDAMP  input.  (Output) 

Application  Calling  Sequence: 

None 

Method: 

case  is  checked  to  see  if  any  FLUTTER  subcases  exist  for  the  current  boundary  condition.  If  not,  control 
is  returned  to  the  MAPOL  sequence.  If  FLUTTER  subcases  exist,  the  dynamic  matrix  descriptions  for  the 
current  subcase  (as  indicated  by  the  SUB  input)  are  brought  into  memory  from  CASE.  Then  the  BGPDT 
data  are  read  into  memory  and  the  DMAPVC  submodule  is  called  to  generate  partitioning  matrices  to 
expand  the  input  matrices  to  the  p-set  from  the  g-set  and  to  strip  off  the  GDR  extra  points  where 
appropriate.  If  extra  points  are  defined,  the  MAA,  KAA,  PHIA,  TMN  and  GSUBO  are  then  expanded  to 
include  the  d-set  extra  point  DOF. 

Following  the  expansion  of  the  input  matrices,  the  direct  matrix  input  M2PP,  B2PP  and  K2PP  are 
assembled  and  reduced  to  the  direct  d-set  DOF  in  the  submodule  dmtoc2.  Modal  transformations  occur 
later  in  the  module.  Following  the  x2PP  formation,  the  vsdamp  data  are  set  depending  on  the  DAMPING 
selection  for  the  flutter  subcase.  Finally,  the  lambda  relation  is  read  into  memory  to  have  the  modal 
frequencies  available  for  modal  damping  computations. 

Following  all  these  preparations,  the  utility  submodules  dmamhh,  dmabhh  and  dmakhh  are  used  to 
assemble  the  modal  mass,  damping  and  stiffness  matrices  accounting  for  all  the  dynamic  matrix  options. 
Control  is  then  returned  to  the  MAPOL  program. 

Design  Requirements: 

1.  The  FLTJTDMA  module  is  intended  to  be  called  once  for  each  flutter  subcase  in  the  boundary  condition. 
The  ordenng  of  subcases  is  that  in  the  CASE  relation.  Each  set  of  dynamic  matrices  in  the  standard 
sequence  is  saved  in  a  doubly  subscripted  set  of  matrices  to  be  used  in  sensitivity  analysis.  It  is  not 
necessary  to  save  these  matrices  unless  the  sensitivity  phase  will  be  performed. 

Error  Conditions: 

1.  Missing  damping  sets  called  for  on  the  flutter  entry  are  flagged. 

2.  Errors  on  tabdmp  entries  are  flagged. 
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Engineering  Application  Module:  FLUTDKV 

Entry  Point:  FLUTDR 

Purpose: 

MAPOL  director  for  flutter  analyses. 

MAPOL  Calling  Sequence: 

CALL  FLUTDKV  (  BC,  SUB,  LOOP  >; 

BC  Boundary  condition  number.  (Integer,  Input) 

sub  Flutter  subcase  number  (ranging  from  1  to  the  total  number  of  flutter 

subcases)  of  the  subcase  to  be  processed  in  this  pass.  (Integer,  Input) 

loop  Logical  flag  indicating  that  more  flutter  subcases  exist  in  the  boundary 

condition.  (Logical,  Output) 

Application  Calling  Sequence: 

None 

Method: 

The  SUB’th  flutter  subcase’s  TITLE,  SUBTITLE  and  label  are  retrieved  from  the  case  relation  and 
set  in  the  /OUTPT2/  common  for  downstream  page  labeling.  If  more  than  sub  flutter  subcases  exist, 
the  loop  flag  is  set  to  true  to  tell  the  MAPOL  sequence  that  more  passes  through  the  flutter  analysis 
modules  are  needed. 

Design  Requirements: 

1.  This  module  is  the  driver  for  a  set  of  MAPOL  modules  that  together  perform  the  FLUTTER  analysis 
for  a  subcase.  These  modules  are  FLUTDM&,  ELUTQHHL  and  FLUTTRAH. 

Error  Conditions: 

None 


136 


Engineering  Application  Module:  FLUTQHHL 
Entry  Point:  FLTQHH 


Purpose: 

Processes  matrix  QKKL  with  normal  modes  for  flutter. 

MAPOL  Calling  Sequence: 

CALL  FLUTQHHL  <  NITER,  BC,  SOB,  ESIZE(BC),  PSIZE(BC),  [QKKL],  [OGTKA] , 

[PHIA],  USET(BC),  [TMN(BC)],  [GSOBO(BC) ] ,  NGDR,  AECCMP0, 
GECMUA,  [PHIKH],  [QHHLFL (BC , SOB) ] ,  OAGRDDSP  ); 


NITER  Design  iteration  number.  (Integer,  Input) 

BC  Boundary  condition  number.  (Integer,  Input) 


SOB 


Flutter  subcase  number.  (Integer,  Input) 


ESIZE (BC) 
PSIZE (BC) 
[QKKL] 

[OGTKA] 

[PHIA] 


Number  of  extra  points  for  the  current  boundary  condition. 

(Integer,  Input) 

Number  of  physical  degrees  of  freedom  in  the  current  boundary  condi¬ 
tions  (GSIZE+ESIZE)  (Integer,  Input) 

Matrix  containing  a  list  of  k  x  k  complex  unsteady  aerodynamic  matrices 
for  each  m-k  pair  defined  by  MKAEROl  and  mkaero2  entries.  These  matri¬ 
ces  were  output  from  the  AMP  module.  (Input) 

The  matrix  of  splinting  coefficients  relating  the  aerodynamic  pressures  to 
forces  at  the  structural  grids  and  relating  the  structural  displacements  to 
the  streamwise  slopes  of  the  aerodynamic  boxes  reduced  to  the  a-set  DOF. 
(Input) 

Matrix  of  normal  modes  eigenvectors  in  the  a-set.  (Input) 


TJSET  (BC) 
[TMN (BC) ] 
[GSOBO (BC) ] 

NGDR 

AECCMPU 

GECMUA 


Current  boundary  condition’s  unstructured  entity  of  set  definition  masks 
(expanded  to  include  extra  points  and  any  gdr  scalar  points)  (Input) 

Multipoint  constraint  transformation  matrix  for  the  current  boundary 
condition.  (Input) 

Static  condensation  or  gdr  reduction  matrix  for  the  current  boundary  con¬ 
dition.  (Input) 

Denotes  dynamic  reduction  in  the  boundary  condition. 

*  o  No  gdr 
=  -1  GDR  is  used 
(Input,  Integer) 

A  relation  describing  aerodynamic  components  for  the  unsteady  aerody¬ 
namics  model.  It  is  used  in  splining  the  aerodynamics  to  the  structural 
model.  (Input) 

A  relation  describing  the  aerodynamic  boxes  for  the  unsteady  aerodynam¬ 
ics  model.  The  location  of  the  box  centroid,  normal  and  pitch  moment  axis 
are  given.  It  is  used  in  splining  the  aerodynamics  to  the  structure  and  to 
map  responses  back  to  the  aerodynamic  boxes.  (Input) 
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[PHIKH] 


[QHHLFL (BC , SUB) ] 


OAGRDDSP 


Application  Calling  Sequence: 

None 
Method: 

The  case  relation  is  read  to  obtain  the  sUB’th  flutter  subcase  parameters:  control  and  airdphnt. 
Then  the  FLUTTER  relation  is  read  for  the  current  subcase  and  the  KLIST  and  EFFID  entries  are 
recovered. 

If  there  is  no  control  matrix,  PHIA  and  USTKA  matrices  are  expanded  to  include  dynamic  degrees  of 
freedom  using  the  utility  module  qhhexp.  GDR  scalar  points  are  handled  to  ensure  that  the  final  matrices 
are  in  the  d-set.  If  a  control  matrix  does  exist,  its  existence  and  conformability  is  checked.  The  DMAFVC 
utility  submodule  is  used  to  create  partitioning  vectors  and  matrix  reduction  matrices  to  allow  reduction 
of  the  control  matrix  to  the  d-set.  The  FLCNTR  submodule  is  then  called  to  append  the  reduced  CONTROL 
matrix  to  the  expanded  UGTKA  matrix.  The  PHIKH  matrix  is  then  computed  as  the  product  of  the 
expanded  phia  and  the  expanded  and  coNTROL-modified  ugtka: 

[PHIKH]  =  [PHID]T[UGTKD] 

Then,  if  control  effectiveness  correction  factors  are  selected  for  the  subcase,  the  PHIKH  matrix  terms  are 
adjusted  by  the  input  factors.  This  completes  the  computation  of  the  PHIKH  output  matrix.  The  input 
airdisp  output  requests  are  then  processed  to  load  the  oagrddsp  relation  with  the  generalized 
displacements  on  the  unsteady  aerodynamic  geometry. 

Finally,  the  QKK  matrices  that  are  associated  with  the  user’s  input  Mach  number  and  KLIST  for  the 
subcase  are  reduced  to  the  generalized  degrees  of  freedom  using  the  PHIKH  matrix. 

[QHHL]  «  [ (PHIKH) ]T[QKKL] [PHIKH] 

The  premultiplication  takes  place  in  one  mpyad  and  the  postmultiplication  is  done  by  looping  over  each 
reduced  frequency  in  the  set,  extracting  the  k  columns  of  each  h  x  k  matrix  and  performing  a  separate 
MPXAD.  The  results  are  then  appended  onto  the  output  QHHL. 

Design  Requirements: 

None 

Error  Conditions: 

1.  control  matrix  errors  in  conformability  are  flagged. 

2.  CONEFFF  errors  are  flagged. 


A  modal  tranformation  matrix  that  relates  the  box-on-box  aerodynamic 
motions  to  unit  displacements  of  the  generalized  structural  coordinates 
(modes).  (Output) 

A  matrix  containing  the  list  of  h  x  h  unsteady  aerodynamics  matrices  for 
the  current  flutter  subcase  related  to  the  generalized  (modal)  coordinates 
and  including  control  effectiveness  (conefff),  extra  points  and  control 
matrix  inputs.  (Output) 

A  relation  containing  the  structural  eigenvectors  (generalized  DOF) 
mapped  to  the  aerodynamic  boxes  for  those  AIRDISP  requests  in  the  Solu¬ 
tion  Control.  These  terms  are  the  columns  of  PHIKH  put  in  relational  form 
to  satisfy  the  output  requests.  (Output) 
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Engineering  Application  Module:  FLUTSENS 

Entry  Point:  FLTSTY 

Purpose: 

Tb  compute  the  sensitivities  of  active  flutter  constraints  in  the  current  active  boundary  condition. 
MAPOL  Calling  Sequence 

CALL  FLUTSENS  (  NITER,  BC,  SOB,  LOOP,  GSIZEB,  NDV,  GLBDES,  CONST,  GMKCT, 
DKVT  ,  OS4CT,  DMVI  ,  CLAMBDA,  LAMBDA,  [QHHLFL (BC , SOB)  ]  , 

[MHHFL (BC , SUB) ] ,  [BHHFL  (BC , SUB) ] ,  [KHHFL (BC , SOB) ] , 
CPHIG(BC)],  [AMAT]  ); 


NITER 

Design  iteration  number  (Integer,  Input) 

BC 

Boundary  condition  identification  number  (Integer,  Input) 

SUB 

Flutter  subcase  number  (ranging  from  1  to  the  total  number  of  flutter 
subcases)  of  the  subcase  to  be  processed  in  this  pass.  (Integer,  Input) 

LOOP 

Logical  flag  indicating  that  more  flutter  subcases  exist  in  the  boundary 
condition.  (Logical,  Input) 

GSIZEB 

The  size  of  the  structural  set  (Integer,  Input) 

NDV 

The  number  of  global  design  variables  (Integer,  Input) 

GLBDES 

Relation  of  global  design  variables  (Character,  Input) 

CONST 

Relation  of  constraint  values  (Character,  Input) 

GMKCT 

Relation  containing  connectivity  data  for  the  DJCVT  sensitivity  matrix 
(Character,  Input) 

DKVI 

Unstructured  entity  containing  the  stiffness  design  sensitivity  matrix  in 
a  highly  compressed  format  (Character,  Input) 

GMMCT 

Relation  containing  connectivity  data  for  the  dmvi  sensitivity  matrix 
(Character,  Input) 

DMVI 

Unstructured  entity  containing  the  mass  design  sensitivity  matrix  in  a 
highly  compassed  format  (Character,  Input) 

CLAMBDA 

Relation  containing  results  of  flutter  analyses  (Character,  Input) 

LAMBDA 

Relational  entity  containing  the  output  from  the  real  eigenanalysis 
(Character,  Input) 

[QHHLFL (BC, SUB)] 

Matrix  list  of  modal  unsteady  aerodynamic  coefficients  (Input) 

[MHHFL (BC , SUB) ] 

Modal  mass  matrix  (Input) 

[BHHFL (BC,3UB) ] 

Modal  flutter  damping  matrix  (Input) 

[KHHFL (BC , SOB) ] 

Modal  flutter  stiffness  matrix  (Input) 

[PHIG(BC) ] 

Matrix  of  real  eigenvectors  in  the  structural  set  (Input) 

[AMAT] 

Matrix  of  constraint  sensitivities  (Output) 
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Application  Calling  Sequence: 

None 

Method: 

The  FLUTSENS  module  is  very  similar  to  the  fluttran  module  except  that  the  const  and  clambda 
relations  control  the  execution  of  the  module  rather  than  the  CASE  relation.  The  module  begins  by 
retrieving  all  the  active  flutter  constraints  from  the  CONST  relation  that  are  associated  with  the  current 
subcase  (sub)  and  determining  the  CLAMBDA  tuples  that  correspond  to  the  active  constraints.  The  next 
task  of  the  module  is  to  prepare  for  the  actual  flutter  sensitivity  analysis  by  setting  up  the  flfact  bulk 
data  and  the  UNMK  data  using  the  FREFL  and  PRUNMK  utilities,  respectively.  The  generalized  mass  and 
damping  matrices  are  then  read  into  memory  and  converted  to  single  precision,  followed  by  the  natural 
frequencies  associated  with  the  computed  eigenvectors.  Lastly,  the  generalized  stiffness  r.  atrix  is  read 
in  and  converted  to  single  precision  and  the  generalized  aerodynamic  influence  coefficients  are  opened 
for  retrieval.  A  final  operation  creates  the  scratch  flutter  eigenvector  matrices  that  will  be  used  in  the 
sensitivity  evaluation. 

For  the  flutter  case,  a  number  of  tasks  are  performed  to  set  up  for  the  current  Mach  number.  These 
consist  of  the  retrieval  of  the  set  of  m-k  pairs  for  the  current  FLUTTER  entry  from  the  UNMK  data  and  the 
set  of  normal  modes  that  are  to  be  omitted.  If  modes  are  omitted,  a  partitioning  vector  is  created  and 
used  to  partition  the  input  phig  matrix  to  include  only  the  desired  normal  modes.  As  a  final  step  before 
the  active  constraint  loop  for  the  current  flutter  set  id,  the  local  memory  required  by  the  flutter 
analysis  submodules  is  retrieved. 

The  module  continues  with  the  loop  on  the  CLAMBDA  tuples  associated  with  the  current  FLUTTER  set 
identification  number.  The  scalar  parameters  identifying  the  flutter  root  are  retrieved  from  CLAMBDA 
and  the  set  of  reduced  frequencies  associated  with  the  QHLL  matrices  for  this  flutter  case  are  retrieved 
from  the  UNMK  data.  The  FA1PKI  submodule  is  called  with  this  data  to  compute  the  interpolation  matrix 
for  the  QHLL  matrix  list  under  the  ORIG  curve  fit  option.  Otherwise,  the  fitting  coefficients  are  computed 
on  the  fly  within  the  QFDRV  family  of  routines.  Then,  the  subset  of  the  full  QHLL  matrix  associated  with 
this  flutter  analysis  is  read  into  core  and  converted  to  single  precision. 

At  this  point,  the  imaginary  part  of  the  QZHB  matrix  is  divided  by  the  reduced  frequency.  Finally,  the 
QFDRV  utility  is  called  to  generate  the  QRS  interpolated  aerodynamic  influence  coefficients  for  the  current 
flutter  eigenvalue.  At  the  same  time  the  QFDRV  module  computes  the  sensitivity  of  this  matrix  to  the 
reduced  frequency  (DQRS).  Finally,  the  flutter  eigenmatrix  is  computed  using  the  FSUBS  submodule.  The 
corresponding  right-hand  eigenvector  is  then  computed,  the  eigenmatrix  is  transposed  and  the  left-hand 
vector  computed.  At  this  point,  the  scalar  (complex)  sensitivities  of  the  mass,  damping,  stiffness  and 
aerodynamics  are  computed  as  outlined  in  Section  10.3  of  the  Theoretical  Manual.  The  flutsens 
module  performs  all  these  computations  using  real  arithmetic.  Finally,  the  2X2  left-hand  side  matrices 
of  equation  10-27  of  the  Theoretical  Manual: 


’  DFU  DF12  ’ 

1  DR  1  -  . 

P2R  *  MR  -  P2I  *  MI  +  KR  +  damping 

df21  df22 

lDI  1 

P2R  *  MI  -  P2I  *  MR  +  KI  +  damping 

are  stored  and  the  left-  and  right-hand  eigenvectors  packed  into  a  scratch  entity.  The  value  damping- is: 

J  -g  *  KI 
j  g  *  KR 

if  structural  damping,  g,  is  included. 
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Similarly,  it  is: 


P1R  *  ~  *  KR  -  P1I  *  —  *  KZ 

CO3  CO3 

P1R  *  —  *  KI  -  P1I  *  —  *  KR 
®3  “3 

if  equivalent  viscous  damping  is  used  at  frequency  C03. 

The  module  then  continues  with  the  next  active  constraint  for  the  current  flutter  entry.  Once  all  the 
active  constraints  are  treated  for  the  current  FLUTTER  entry,  the  matrix  of  left-  and  right-hand 
eigenvectors  are  expanded  to  physical  coordinates  using  the  (partitioned)  normal  modes  matrix.  The 
flcsty  module  is  then  called  to  complete  the  solution  of  the  constraint  sensitivities  to  the  global  design 
variables.  These  computations  involve  the  eigenvectors  and  the  mass,  damping  stiffness  sensitivities  to 
compute  the  right-hand  side  of  Equation  10-27  of  the  Theoretical  Manual.  Once  the  FLCSTY  module  is 
complete,  the  flutsens  module  proceeds  with  the  next  FLUTTER  entry  with  active  flutter  constraints. 
When  all  have  been  completed,  control  is  returned  to  the  executive. 

Design  Requirements: 

1.  The  module  assumes  that  at  least  one  active  flutter  constraint  exists  in  the  current  boundary 
condition. 

Error  Conditions: 

None 
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Engineering  Application  Module: 

Entry  Point:  FLUTAN 

Purpose: 


FLUTTRAN 


lb  perform  flutter  analyses  in  the  current  boundary  condition  and  to  evaluate  any  flutter  constraints  if 
it  is  an  optimization  boundary  condition  with  applied  flutter  constraints. 

MAPQL  Calling  Sequence: 

CALL  FLUTTRAN  (  NITER,  BC,  SUB,  [QHHLFL (BC , SUB)  ]  ,  LAMBDA,  HSIZE(BC), 

ESIZE(BC),  [MHHFL (BC , SUB) ] ,  [BHHFL (BC , SUB) ] ,  [KHHFL (BC , SUB) ] , 
CLAMED  A,  CONST  ) ; 


NITER 

BC 

SUB 

[QHBLFL (BC , SUB) ] 
LAMBDA 

BSIZE (BC) 

ESIZE (BC) 

[MHHFL (BC, SUB)  ] 
[BHHFL (BC, SUB)] 
[KHHFL (BC, SUB) ] 
C LAMBDA 
CONST 


Design  iteration  number  (Integer,  Input) 

Boundary  condition  identification  number  (Integer,  Input) 

Flutter  subcase  number  (ranging  from  1  to  the  total  number  of  flutter 
subcases)  of  the  subcase  to  be  processed  in  this  pass.  (Integer,  Input) 

Matrix  list  of  modal  unsteady  aerodynamic  coefficients  (Input) 

Relational  entity  containing  the  output  from  the  real  eigenanalysis 
(Input) 

Number  of  modal  dynamic  degrees  of  freedom  in  the  current  boundary 
condition  (Input) 

The  number  of  extra  point  degrees  of  freedom  in  the  boundary  condition 
(Integer,  Input) 

Modal  mass  matrix  (Input) 

Modal  flutter  damping  matrix  (Input) 

Modal  flutter  stiffness  matrix  (Input) 

Relation  containing  results  of  flutter  analyses  (Character,  Output) 
Relation  of  constraint  values  (Character,  Input) 


Application  Calling  Sequence: 
None 


Method: 

The  FLUTTRAN  module  begins  by  retrieving  the  flutter  discipline  entries  from  the  CASE  relation  for  the 
current  boundary  condition.  If  the  boundary  condition  is  an  optimize  boundary  condition,  the  CONST 
and  CLAMBDA  relations  are  opened  to  store  the  constraint  and  root  extraction  data  needed  for  the 
optimization  task.  For  analysis  boundary  conditions,  the  hidden  entities  FLUTMODE  and  FLUTREL  are 
opened  and  initialized  to  prepare  for  possible  flutter  mode  shape  storage.  These  mode  shapes  are  stored 
so  that  the  OFPDISP  module  can  satisfy  flutter  mode  shape  print  requests. 

The  next  task  of  the  module  is  to  prepare  for  the  actual  flutter  analysis  by  setting  up  the  FLFAGT  bulk 
data  and  the  UNMK  data  using  the  PREFL  and  BRUNMK  utilities,  respectively.  Then  the  reference  unsteady 
aerodynamic  model  data  is  retrieved  from  the  aero  relation.  Lastly,  the  velocity  conversion  factor,  if  one- 
has  been  defined,  is  read  from  the  convert  relation.  The  generalized  mass  and  damping  matrices  are 
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then  read  into  memory  and  converted  to  single  precision,  followed  by  the  natural  frequencies  associated 
with  the  computed  eigenvectors.  Lastly,  the  generalized  stiffness  matrix  is  read  in  and  converted  to 
single  precision  and  the  generalized  aerodynamic  influence  coefficients  are  opened  for  retrieval.  This 
completes  the  preparations  for  the  flutter  discipline  loop. 

For  the  suB’th  flutter  discipline  requested  in  the  CASE  relation,  a  number  of  tasks  are  performed  to  set 
up  for  the  Mach  number  requested  on  the  FLUTTER  entry.  These  consist  of  the  retrieval  of  the  set  of  m-k 
pairs  for  the  current  FLUTTER  entry  from  the  UNMK  data  and  the  lists  velocities  (which  are  converted  to 
the  proper  units,  if  necessary)  and  densities.  If  the  boundary  condition  is  an  optimization  boundary 
condition,  the  table  of  required  damping  values  is  prepared  using  the  prfcon  utility.  Lastly,  the  set  of 
normal  modes  that  are  to  be  omitted  are  retrieved  and  the  data  prepared  to  perform  the  "partitioning'’ 
of  the  generalized  matrices.  As  a  final  step  before  processing  the  current  flutter  entry,  the  local 
memory  required  by  the  flutter  analysis  submodules  is  retrieved. 

The  subset  of  m-k  pairs  in  the  QHLL  matnx  list  for  the  current  Mach  number  is  determined  and  the  set 
of  associated  reduced  frequencies  determined.  The  FA1PKX  submodule  is  called  with  this  data  to  compute 
the  interpolation  matrix  for  the  QHLL  matrix  list  if  the  OrOlG  curve  fit  is  used.  Otherwise,  the  fitting 
coefficients  are  computed  on  the  fly  in  the  QFDRV  module.  Then,  the  subset  of  the  full  QHLL  matrix 
associated  with  this  flutter  analysis  is  read  into  core  and  converted  to  single  precision.  At  this  point,  the 
imaginary  part  of  the  qzhh  matrix  is  divided  by  the  reduced  frequency.  Finally,  the  Mach  number 
dependent  memory  blocks  are  retrieved  and  the  inner-most  analysis  loop  on  the  density  ratios  is  begun. 

For  each  density  ratio  associated  with  the  Mach  number  for  the  current  flutter  analysis  discipline,  the 
fluttran  module  performs  the  flutter  analysis.  There  are  two  distinct  paths  through  the  inner  loop: 
one  for  optimization  and  one  for  analysis.  They  differ  in  that  the  analysis  loop  refines  the  set  of  user 
selected  v  elocities  to  find  a  flutter  crossing,  while  the  optimization  path  computes  the  flutter  eigenvalues 
only  at  the  user  specified  velocities  and  computes  the  correspond ng  flutter  constraint  value  based  on 
the  required  damping  table.  Once  all  the  loops  have  been  completed,  the  module  returns  control  to  the 
executive. 

Design  Requirements: 

1.  The  module  assumes  that  at  least  one  flutter  subcase  exists  in  the  current  boundary  condition. 

Error  Conditions: 

I.  Referenced  data  on  flutter  entries  that  do  not  exist  on  the  data  base  are  flagged  and  the  execution 
is  terminated. 
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Engineering  Application  Module:  FREDUC’S 


Entry  Point:  FREDUC 


Purpose: 

lb  reduce  the  symmetric  or  asymmetric  f-set  stiffness,  mass  and/or  loads  matrix  to  the  a-set  if  there  are 
omitted  degrees  of  freedom. 

MAFOL  Calling  Sequence: 

CALL  FREDOCE  (  [KFF],  [PF] ,  [PFOA(BC)],  SYM,  [KOOINV (BC) ] ,  [KOOU(BC)], 

[KAO(BC) ] ,  [GSOBO (BC) ] ,  [KAA] ,  [PA],  [PO] ,  OSET(BC)  ); 


[KFF] 

[PF] 

[PFOA(BC) ] 

3YM 

[KOOINV  (BC)] 

[KOOO(BC)  ] 

[KAO  (BC)  ] 

[GSOBO  (BC)  ] 

[XAA] 

[PA] 

[PO] 

USET (BC) 


Optional  Stiffness  or  mass  matrix  to  be  reduced  (Input) 

Optional  loads  matrix  to  be  reduced  (Input) 

The  partitioning  vector  splitting  the  free  degrees  of  freedom  into  the 
analysis  set  and  the  omitted  degrees  of  freedom  (Input) 

Optional  symmetry  flag;  =1  if  KFF  is  not  symmetric  (Integer,  Input) 

Matrix  containing  the  inverse  of  KOO  for  symmetric  stiffness  matrices  or 
the  lower  triangular  factor  of  KOO  for  asymmetric  matrices  (Output) 

Optional  matrix  containing  the  upper  triangular  factor  of  KOO  for  asym¬ 
metric  stiffness  matrices  (Output) 

Optional  matrix  containing  the  off-diagonal  partition  of  KFF  required  for 
recovery  when  KFF  is  asymmetric  (Output) 

Matrix  containing  the  static  condensation  transformation  matrix 
(Input  and  Output) 

The  stiffness  matrix  in  the  analysis  set  degrees  of  freedom  (Output) 

The  loads  matrix  in  the  analysis  set  degrees  of  freedom  (Output) 

Matrix  containing  the  loads  on  the  omitted  degrees  of  freedom  (Output) 
The  unstructured  entity  defining  structural  sets  (Character,  Input) 


Application  Calling  Sequence: 
None 


Method: 

FREDOCE  module  begins  by  checking  if  the  KFF  argument  is  nonblank.  If  so,  the  reduction  by  static 
condensation  is  performed  in  one  of  two  ways  depending  on  the  SYMflag.  If  the  SYMflag  is  zero  or  omitted 
from  the  calling  sequence  the  following  operations  are  performed: 


[KFF]  -4 


KOO  KOA 
KAA 


[KOOINV]  *  [KOO]-1  symmetric  decomposition 


[GSOBO]  »  -  [KOOINV]  [KOA]  symmetric  Forward-Backward  Substition 


[KAA]  =  [KAA]  +  [KOA]T  [GSOBO] 
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The  rooinv,  gsubo  anti  KAA  arguments  must  be  nonblank  in  the  calling  sequence.  If  the  SYMflag  is 
nonzero  in  the  calling  sequence  the  following  operations  are  performed: 


[PF]  -> 


KOO 

KAO 


KOA  ' 
KAA 


[Kogxnv]  is  the  Lower  triangular  factor  of  [koo] 


tKOOU]  is  the  Upper  triangular  factor  of  [KOO] 

[GSUBO]  *  -  [KOO] -1  [KOA]  asymmetric  Forward-Backward  Substition 
[KAA]  =  [KAA]  +  [KAO] [GSUBO] 


The  KOOXNV,  KOOU,  KAO,  gsubo  and  KAA  arguments  must  be  nonblank  in  the  calling  sequence.  Note 
that  KAO  is  required  since  the  asymmetric  nature  of  KFF  prohibits  the  transpose  operation  used  in  the 
symmetric  case.  The  module  then  checks  if  PF  is  nonblank.  If  so,  the  loads  matrix  reduction  is  performed. 
Once  again,  there  are  two  paths  depending  on  the  symmetry  flag.  If  sym  is  zero  (symmetric),  the  following 
operations  are  performed: 

PO 

[pjn  ->  {s; 

[SCRl]  *  [PO]T [GSUBO] 

[SCR2]  =  [SCR1]T 
[PA]  -  [PA]  +  [SCR2] 


With  the  odd  order  of  operations  dictated  by  efficiency  considerations  in  the  matrix  operations.  Note 
that  the  gsubo,  pa  and  PO  arguments  must  be  nonblunk  with  the  gsubo  argument  an  input  if  the 
stiffness  matrix  was  not  simultaneously  reduced.  If  SYM  is  nonzero  (asymmetric),  the  following  opera¬ 
tions  are  performed: 


[SCRl]  =  [KOO]-1  [PO]  (Asymmetric  STBS) 

[PA]  *  [PA]  +  [KAOj  [SCRl] 

Note  that  the  XOOINV  KOOU,  KAO,  PA  and  PO  arguments  must  be  supplied  with  the  KOOIRV,  KOOU, 
«id  kao  arguments  input  if  the  (asymmetric)  stiffness  matrix  is  not  being  reduced  in  the  same  call. 

Design  Requirements: 

None 


Error  Conditions: 
None 
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Engineering  Application  Module:  freqsens 
Entry  Point:  FQCSTY 


Purpose: 

lb  compute  the  sensitivities  of  active  frequency  constraints  in  the  current  active  boundary  condition. 
MAPOL  Calling  Sequence: 

CAXiL  FREQSENS  {  NITER,  BC ,  NDV,  GLBDES ,  CONST,  LAMBDA,  GMECT,  DKVI ,  GMMCT, 

DMVI,  (PEIG(BC)],  [AMAT]  ); 

Design  iteration  number  (Integer,  Input) 

The  current  boundary  condition  number  (Integer,  Input) 

Number  of  design  variables  (Integer,  Input) 

Relation  of  global  design  variables  (Character,  Input) 

Relation  of  constraint  values  (Character,  Input) 

Relational  entity  containing  the  output  from  the  real  eigenanalysis 
(Input) 

Relation  containing  connectivity  data  for  the  DKVI  sensitivity  matrix 
(Character,  Input) 

Unstructured  entity  containing  the  stiffness  design  sensitivity  matrix  in 
a  highly  compressed  format  (Character,  Input) 

Relation  containing  connectivity  data  for  the  DMVI  sensitivity  matrix 
(Character,  Input) 

Unstructured  entity  containing  the  mass  design  sensitivity  matrix  in  a 
highly  compressed  format  (Character,  Input) 

Matrix  of  eigenvectors  for  the  current  boundary  condition  (Input) 

Matrix  containing  the  sensitivities  of  the  constraints  to  the  design  vari¬ 
ables  (Output) 

Application  Calling  Sequence: 

None 

Method: 

The  module  begins  by  collecting  design  variable  information  from  GLBDES,  frequency  constraint 
information  from  const  and  eigenvalue  information  from  LAMBDA.  Space  is  reserved  for  design 
sensitivity  matrices  and  then  the  number  of  eigenvectors  that  can  be  held  in  core  simultaneously  is 
determined.  Spill  logic  is  provided  if  this  number  is  less  than  the  number  of  eigenvectors  that  have 
eigenvalue  constraints.Ths  eigenvectors  are  read  into  core  and  a  loop  on  the  design  variables  brings  the 
connectivity  data  into  core.  Calls  to  tukmls/d  perform  the  required  triple  matrix  products  involving 
the  eigenvector  and  the  design  sensitivity  matrices.  This  information  is  required  to  form  the  frequency 
constraint  information,  which  i?  written  to  the  AMAT  matrix. 


NITER 

BC 

NDV 

GLBDES 

CONST 

LAMBDA 

GMKCT 

DKVI 

GMMCT 

DMVI 

[PHIG (BC) ] 
(AMAT  3 
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Design  Requirements: 

1-  The  moduie  is  only  called  >f  there  are  active  frequency  constraints  and  therefore  must  follow  the 
abound  module. 

2.  The  nstJuQJ  module  makes  the  assumption  that  data  were  written  to  from  this  module  prior  to 
any  subcase  dependent  sensitivities. 

terror  Conditions: 

None 
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Engineering  Application  Module:  FSD 


Entry  Point:  FSDDRV 
Purpose: 

lb  perform  redesign  by  Fully  Stressed  Design  (FSD)  methods  based  on  the  set  of  applied  stress 
constraints.  All  other  applied  constraints  are  ignored. 

MAPOL  Calling  Sequence: 

CALL  FSD  (  NDV,  NITER,  FSDS,  FSDE,  MPS,  OCS,  ALPHA,  CNVRGLIM,  QLEDES , 

LOCLVAR,  [PTRANS] ,  CONST,  APPCNVRG,  CTL,  CTIiCN,  DESHIST  ) ; 


NDV 

NITER 

FSDS 

FSDE 

MPS 

OCS 

ALPHA 

CNVRGLIM 

GLBDES 

LOCLVAR 

[PTRANS] 

CONST 

APPCNVRG 

CTL 

CTLMIN 

DESHIST 


The  number  of  global  design  variables  (Integer,  Input) 

Iteration  number  for  the  current  design  iteration  (Integer,  Input) 

The  first  iteration  to  use  FSD  (Integer,  Input) 

The  last  iteration  to  use  FSD  (Integer,  Input) 

The  first  iteration  to  use  math  programming  (Integer,  Input) 

The  first  iteration  to  use  optimality  criteria  (Integer,  Input) 

Exponential  move  limit  for  the  FSD  algorithm  (Real,  Input) 

Relative  percent  change  in  the  objective  function  that  indicates  approxi¬ 
mate  problem  convergence  (Real,  Input) 

Relation  of  global  design  variables  (Character,  Input) 

Relation  containing  the  relationship  between  local  variables  and  global 
variables  in  the  design  problem  (Character,  Input) 

The  design  variable  linking  matrix  (Character,  Input) 

Relation  of  constraint  values  (Character,  Input) 

The  approximate  problem  converge  flag  (Logical,  Output) 

**  FALSE  if  not  converged 

=  true  if  converged  in  objective  function  value  and  design  vector  move 
Tolerance  for  indicating  an  active  constraint  (Real,  Output) 

Tblerance  for  indicating  a  violated  constraint  (Real,  Output) 

Relation  of  design  iteration  information  (Character,  Output) 


Application  Calling  Sequence: 

None 

Method: 

The  first  task  performed  in  the  FSD  module  is  to  determine  if  the  FSD  option  is  to  be  used.  The  assumption 
of  the  module  is  that  the  Solution  Control  STRATEGY  requests  have  been  satisfied  by  the  MAPOL 
sequence  such  that,  if  FSD  is  called,  FSD  has  been  requested  by  the  user  for  this  iteration. 

The  module  checks  that  the  alpha  parameter  is  a  legal  value  (X) .  0).  If  it  is  not,  the  default  value  of 
0.60  is  used.  Then  FSD  brings  the  required  data  into  memory.  These  data  consist  of  the  local  design 
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variable  data  (in  the  PTRANs,  LOCLVAR  and  GLBDES  entities),  which  are  accessed  through  the  design 
variable  utility  module  PRELDV  with  entry  points  LDVPNT  and  GETLDV.  Finally,  the  CONST  relation  tuples 
associated  with  the  stress  constraints  are  retrieved.  If  no  stress  constraints  are  found,  the  module  cannot 
do  any  resizing  and  so  modifies  the  MAPOL  control  parameters  fsds,  fsde,  mps  and  ocs  as  outlined 
below  to  prevent  the  further  use  of  fsd  in  subsequent  iterations. 

If  the  appropriate  constraints  were  found,  the  module  loops  through  each  local  design  variable  and 
determines  winch  (if  any)  stress  constraint  is  associated  with  that  variable.  When  the  matching 
constraint  is  found,  the  new  local  variable  is  computed  from: 

tnew  —  (g  +  1.0  )a 

If  any  shape  function  linked  local  variables  are  encountered  during  this  phase,  the  starting  and  ending 
iterations  (fsds  and  FSDE)  and  the  appropriate  other  starting  iteration  number  (the  lesser  of  MPS  and 
OCS)  are  modified  such  that  FSD  will  not  be  called  again.  Then  execution  is  returned  to  the  executive. 
This  prevents  any  further  attempts  to  use  FSD  with  the  shape  function  linking  and  directs  that  the 
current  iteration  be  performed  used  the  appropriate  alternative  method.  A  warning  is  given  and  the 
execution  continues. 


Once  the  vector  of  new  local  variables  are  retrieved,  the  P TRANS  data  is  brought  into  memory  along  with 
the  qlbdes  data.  The  glbdes  data  are  used  to  reset  any  local  variable  values  that  are  outside  their 
valid  ranges  to  maximum  or  minimum  gauge.  Then  the  new  vector  of  global  variables  are  computed  as: 


Vnew  —  max 
p, 


tnew 


These  constitute  the  new  design  from  the  FSD  algorithm  and  are  stored  back  to  the  GLBDES  relation. 
The  deshist  relation  is  updated  and  an  informational  message  indicating  the  changes  in  the  objective 
function  is  written.  The  active  and  violated  constraint  tolerances  are  set  to  their  FSD  default  values: 
ctl=-1.0  *  10"3  and  ctimin=5.  OjcIO-3.  This  completes  the  action  of  the  FSD  module. 


Design  Requirements: 

1.  Only  stress  constraints  (strain  constraints  are  excluded)  are  considered  in  the  FSD  module.  If  none 
are  found,  the  module  terminates  cleanly  with  the  FSD  selection  flags  reset  to  avoid  any  further  FSD 
cycles. 


2.  Shape  function  design  variable  linking  causes  the  module  to  terminate  cleanly  with  the  FSD  selection 
flags  reset  to  avoid  any  further  FSD  cycles. 

Error  Conditions: 


None 
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Engineering  Application  Module:  GDR1 

Entry  Point,:  GDRDR1 


Purpose: 

Tb  compute  the  shifted  stiffness  matrix  and  the  rigid  body  transformation  matrix  [GGO]  to  be  used  in 
phase  2  of  Generalized  Dynamic  Reduction. 


MAPOL  Calling  Sequence: 

CAM.  GDRl  (  [500],  [KCfO]  ,  [KSOO] ,  [GGO],  LKSET,  LJSET,  NEIV,  EM&X,  BC, 
BGHJTfSC},  USET(EC),  MCHIT,  LSIZE  ); 


[KOO] 

[MOO] 

[KSOO] 

[GGO] 

LKSET 

LJSET 
NS  IV 


BC 

BGHJT  (BC) 
OSET(BC) 
NCSQIT 
LSIZE 


Stiffness  matrix  in  the  o-set  (Input) 

Mass  matrix  in  the  o-set  (Input) 

Shifted  500  matrix  (Output) 

Matrix  to  compute  displacements  at  the  g-set  due  to  displacements  at  the 
origin  (Output) 

Length  of  the  k-aet  vectors,  LKSET  «  -1  if  there  is  no  k-set 
(Integer,  Output) 

Length  of  the  j-aet,  LJSET*  -1  if  there  is  no  jset 

Computed  number  of  eigenvalues  below  EMftX  (Integer,  Output) 

Maximum  frequency  of  inteiest.  This  is  user  supplied  through  the 
dynred  entry,  but  may  be  modified  after  output  to  give  the  desired  num¬ 
ber  of  eigenvalues  on  input  to  GDR2  (Real, Output) 

The  current  boundary  condition  (integer,  Input) 

Relation  of  basic  grid  point  coordinate  data  (Input) 

The  unstructured  entity  defining  structural  sets  (Input) 

The  number  of  DOF  in  the  o-set  (Integer,  Input) 

The  number  of  DOF  in  the  L-set  (Integer,  Input) 


Application  Calling  Sequence: 
None 


Method: 

The  module  begins  by  calling  subroutine  GDR1S  to  input  bulk  data  information,  hejv,  the  number  of 
eigenvalues,  is  then  determined  using  fmax  and  the  Sturm  sequence  theorem.  The  LJSET  parameter  is 
computed  as  a  combination  of  structural  DOF  in  the  a-uet  plus  any  user  input  nonstructural  DOF.  The 
LKSET  parameter  is  specified  to  be  1 . 5  *NEIV  and  the  sliift  parameter  is  computed  based  on  WAX, 
LKSET  and  the  machine  precision.  The  shifted  stiffness  matrix  is  then  computed,  the  GGO  matrix  is 
computed  and  control  is  returned  to  the  executive. 


360 


Design  Requirements: 

1.  This  module  is  an  alternative  to  Guyan  reduction  and  therefore  parallels  the  reduction  to  the  a-set. 
Error  Conditions: 

1.  j-set  DOP  have  been  constrained 

2.  o-set  does  not  exist 

3.  Only  a  subset  of  roots  are  guaranteed  to  be  accurate. 


151 


Engineering  Application  Module:  GDR2 

Entry  Point:  GDRDK2 

Fu'/pose: 

lb  compute  the  orthogonal  basis  [PHIOK]  for  the  subspace  to  be  used  in  phase  3  of  Generalized  Dynamic 
Reduction. 


MAPOL  Calling  Sequence: 


(  [LSOO] ,  [MOO]  ,  [PHI OK] ,  LKSET,  LJSET ,  NEIV,  FMAX,  BC  ) ; 
Decomposed  shifted  stiffness  matrix  (Input) 

Mass  matrix  in  the  o-set  (Input) 

Matrix  of  approximate  vectors  (Output) 

Length  of  the  k-set  vectors  (Integer,  Input) 

Not  used 

Number  of  eigenvalues  below  nsMt  (Integer,  Input) 

Maximum  frequency  of  the  NEIV  eigenvalues  (Real, Input) 

The  current  boundary  condition  (Integer,  Input) 


CALL  GDR2 
[LSOO] 

[MOO] 

[PEI OK] 

LKSET 
LJSET 
NEIV 
FMAX 
BC 

Application  Calling  Sequence: 

None 

Method: 

After  performing  initialization  tasks,  random  starting  vectors  are  generated  and  an  iteration  procedure 
is  performed  to  obtain  an  initial  set  of  solution  vectors.  These  solution  vectors  are  transformed  into  a 
orthogonal  base  for  the  approximate  vectors.  If  an  insufficient  number  ( «  LKSET )  vectors  are  generated 
by  this  process,  additional  solution  vectors  are  obtained  and  transformed. 

Design  Requirements: 

1.  This  module  follows  GDR1  and  a  decomposition  of  R300  into  LSOO. 

2.  If  LKSET  is  zero  in  the  standard  MAPOL  sequence,  GDR2  is  not  called. 

Error  Conditions: 

None 
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Engineering  Application  Module:  GDR3 

Entry  Point:  GDRDR3 

Purpose: 

lb  compute  the  transformation  matrix  [GS0BO]  for  Generalized  Dynamic  Reduction. 

MAPOL  Calling  Sequence: 

CALL  GDR3  (  [KOO]  ,  [XOA]  ,  [MGG]  ,  [PSIOK]  ,  [TMN  (BC)  ]  ,  [GGO]  ,  [PGMN  (BC)  ]  , 

[PNSF(BC)],  [PFOA(BC) ] ,  [GSOBO(BC)],  BGPDT(BC) ,  USET (BC) ,  LKSET, 
LJSET,  ASIZE,  GHORM,  BC  ); 


[KOO] 

[KOA] 

[MGG] 

[PHIOK] 

[TMN  (BC)  ] 
[GGO] 

[BGMN(BC)] 

[PKSF(BC) ] 

tPFOA(BC)] 

[GSUBO (BC) ] 

BGPDT (BC) 

USET (BC) 

LKSET 

LJSET 

ASIZE 

GKOBM 

BC 


Stiffness  matrix  in  the  o-set  (Input) 

Partition  of  the  stiffness  matrix  (Input) 

Mass  matrix  in  the  g-set  (Input) 

Matrix  of  approximate  eigenvectors  (Input) 

Matrix  relating  m-set  and  n-set  DOF’s  (Input) 

Rigid  body  transformation  matrix  (Input) 

Partitioning  vector  from  g  to  m  and  n-sets  (Input) 

Partitioning  vector  from  n  to  s  and  f-sets  (Input) 

Partitioning  vector  from  f  to  o  and  a-sets  (Input) 

General  transformation  matrix  for  dynamic  reduction  (Output) 
Relation  of  basic  grid  point  coordinate  data  (Input) 

The  unstructured  entity  defining  structural  sets  (Input) 

Length  of  the  k-set  (Integer,  Input) 

Length  of  the  j-set  (Integer,  Input  and  Output) 

The  number  of  DOFs  in  the  A-set  (Integer,  Input) 

The  sum  of  LKSET  and  LJSET  (Integer,  Output) 

The  current  boundary  condition  (Integer,  Input) 


Application  Calling  Sequence: 

None 

Method: 

The  module  calculates  an  overall  transformation  matrix  which  relates  DOF’s  in  the  a-,  j-  and  k-sets  to 
the  o-set.  The  task  is  simplified  if  some  of  the  sets  are  empty. 
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Design  Requirements: 

1.  This  module  must  follow  GDRI. 

2.  If  LRSET  is  nonzero,  GDR2  must  also  have  been  called. 
Error  Conditions: 

None 
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Engineering  Application  Module:  GDR4 
Entry  Point:  GDRDR4 


Purpose: 

Tb  compute  updated  transformations  between  displacement  sets.  Useful  for  data  recovery  from  Gener¬ 
alized  Dynamic  Reduction. 

MAPOL  Calling  Sequence: 

CALL  GDR4  (  BC,  GSIZE,  PSIZE(BC),  LKSET,  LJSET,  NOMOPTBC,  NBNDCOND, 

[PGMN(BC)],  [TMN(BC)],  EPNSF(BC)],  [PFCA(BC)],  [t'ARL (BC)  ]  , 

[PQDRG 'BC) ] ,  [PAJK] ,  [PFJK] ,  BGPDT(BC),  USET(BC)  ); 


BC 

GSXKE 
PSIZE (EC) 

LKSET 
LJSET 
NUMOPTBC 
NBHDCOKD 
[PGMN  (BC)  ] 
ETE4S  (BC)  ] 
[PNSF(BC)] 
[PFOA(BC) ] 
EPARL (BC) ] 
EPGDRG(BC)] 

EPAJK] 

[PFJK] 

BGPDT(BC) 

U3ET (BC) 


The  current  boundary  condition  (Integer,  Input) 

Length  of  the  g-set  vector  (Integer,  Input) 

The  size  of  the  physical  set  for  the  current  boundary  condition.  (Integer, 
Input) 

Length  of  the  k-set  (Integer,  Input) 

Length  of  the  j-set  (Integer,  Input) 

Tbtal  number  of  optimization  boundary  conditions  (Integer,  Input) 

Thtal  number  of  boundary  conditions  (Integer,  Input) 

Partitioning  vector  from  g  to  m  and  n-sets  (Input) 

Matrix  relating  m-set  and  n-eet  DOF’s  (Input) 

Partitioning  vector  from  ri  to  s  and  f-sets  (Input) 

Partitioning  vector  from  f  to  o  and  a-sets  (Input) 

Modified  partitioning  vector  to  partition  the  a-set  to  r  and  1-sets  (Output) 

A  partitioning  vector  that  removes  the  additional  gdr  scalar  points  from 
the  g-set  sized  displacement  and  acceleration  vectors.  (Output) 

Partitioning  vector  to  divide  the  a-set  DOFs  that  may  include  GDR  gener¬ 
ated  scalar  points  into  the  original  a-set  DOFs.  (Output) 

Partitioning  vector  to  divide  the  f-set  DOFs  that  may  include  GDR  gener¬ 
ated  scalar  points  into  the  original  f-set  DOFs.  (Output) 

gdr  modified  relation  of  basic  grid  point  coordinate  data  which,  on  out¬ 
put,  will  include  the  scalar  points  generated  by  GDR.  (Input  and  Output) 

GDR  modified  unstructured  entity  defining  structural  sets  which,  on  out¬ 
put,  will  include  the  scalar  points  generated  by  gdr.  (Input  and  Output) 


Application  Calling  Sequence: 
None 
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Method: 


The  module  computes  the  partitioning  matrix  pgdrg  to  allow  reduction  of  the  downstream  g-set  matrices 
to  be  only  the  original  g-set  (before  gdr  scalar  points  were  added).  Similarly  the  pfjk  partitioning  vector 
does  the  same  for  f-set  matrices.  The  USET  and  bgpdt  entities  are  updated  to  include  the  GDR  extra 
points  (which  are  assigned  external  id’s  greater  than  any  existing  scalar  points  and  internal  id’s  greater 
than  the  g-size).  These  degrees  of  freedom  will  belong  to  the  k-  and/or  j-sets.  Lastly,  a  modified  PARL 
partitioning  vector  is  also  computed  in  which  the  a-set  are  the  generalized  GDR  degrees  offreedom  (scalar 
points  and/or  physical  DOF)  and  the  r-set  are  the  support  point  DOFs. 

Design  Requirements: 

1.  This  is  the  final  module  in  the  gdr  sequence 
Error  Conditions: 

None 
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Engineering  Application  Module:  GPWG 
Entry  Point:  GPWG 


Purpose: 

Grid  point  weight  generator. 

MAPOL  Calling  Sequence: 

CfflL  GPWG  (  NITER,  BC,  GPWGGRID,  [MGG]  ,  OGFWG  ); 

niter  Design  iteration  number.  (Optional,  Integer,  Input) 

SC  Boundary  condition  number.  (Integer,  Input) 

gprggrid  Relation  containing  the  data  from  the  GPWG  Bulk  Data  entries.  (Input) 

[MGG]  Mass  matrix  in  the  g-set.  (Input) 

ogfmG  Relation  of  Grid  Point  Weight  Generation  Output.  (Output) 

Application  Calling  Sequence: 

None 


Method: 

The  existence  of  the  HOG  matrix  is  checked  first  If  it  does  not  exist  or  has  no  columns,  control  is  returned 
to  the  MAPOL  sequence  without  error.  Then  the  CASE  relation  is  read  for  the  current  boundary  condition 
to  determine  if  any  GPWG  print  or  punch  requests  exist.  If  not,  the  module  terminates. 

The  invariant  basic  grid  point  data  are  read  from  BSPDT  and  checked  to  ensure  that  at  least  one  grid 
point  exists.  If  all  the  points  are  scalar  points,  the  module  terminates  without  warning.  Then  the 
CONVERT/MASS  entry  is  recovered  (if  one  exists)  to  allow  output  of  the  Grid  Point  Weight  from  the  mass 
matrix.  Then  the  coordinates  of  the  reference  point  are  found  from  the  first  GPWG  entry  in  the  GPWGGRID 
relation  or  are  set  to  {0 . 0 , 0 . 0 , 0 . 0}. 

The  grid  point  weight  is  then  computed  and  the  results  are  stored  on  the  ogpwg  relation.  If  a  print 
request  exists  for  the  current  design  iteration  or  analyse  boundary  condition,  the  results  are  read  from 
ogpwg  and  printed  to  the  output  file. 

Design  Requirements: 

None 


Error  Conditions: 
None 
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Engineering  Application  Module: 

Entry  Point:  GREDUC 


GREDUCE 


Purpose: 


lb  reduce  the  symmetric  g-set  stiffness,  mass  or  loads  matrix  to  the  n-set  if  there  are  multipoint 
constraints  in  the  boundary  condition. 

MAPOL  Calling  Sequence: 

CALL  GREDUCE  (  [KQG] ,  [PG]  ,  [PGMN(BC)],  [OMN(BC)],  [KNNJ ,  [PN]  ); 


[KGG] 

[PG] 

[PGMN(BC)  ] 
[3MN{*C)  ] 


Optional  matrix  containing  the  global  stiffness  or  mass  matrix  to  be  re¬ 
duced  (Input) 

Optional  matrix  containing  the  global  applied  loads  to  be  reduced  (Input) 

The  partitioning  vector  splitting  the  structural  degrees  of  freedom  into 
the  independent  and  the  multipoint  constraint  degrees  of  freedom  (Input) 

The  transformation  matrix  for  multipoint  constraints  (Input) 


[KNN] 

[PN] 


Optional  matrix  containing  the  reduced  kgg  matrix  for  the  independent 
degrees  of  freedom  (Output) 

Optional  matrix  containing  the  reduced  PG  matrix  for  the  independent  de¬ 
grees  of  freedom  (Output) 


Application  Calling  Sequence: 
None 


Method: 

The  GREDUCE  utility  module  performs  the  multipoint  constraint  reduction  on  the  stiffness  and/or  mass 
and/or  loads  matrix  based  on  the  presence  or  absence  of  input  arguments.  The  only  required  arguments 
are  the  partitioning  vector  pgmn  and  the  rigid  body  transformation  matrix  tMN.  If  the  KGG  argument  is 
not  omitted,  the  following  operations  are  performed  using  the  large  matrix  utilities: 


[KGG]  -4 

["  KHM 

KMN  " 

1  Kl®4 

KNN 

[3CR1]  * 

[KNN] 

+  [KNM]  [TMH] 

[SCR2]  « 

[3CR1] 

+  [1MN]T[KMN] 

[3CR1]  » 

[KMM]  [SMN] 

[SCR2]  « 

[SCR1] 

+  [TMN]T[KMN] 

[KNN]  « 

[SCR2] 

+  [SMN]T[KMN] 

These  operations  require  the  creation  of  four  scratch  matrix  entities  for  the  intermediate  results  and 
the  partitions  of  the  KGG  matrix. 
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If  the  PC3  argument  is  not  omitted,  the  following  operations  are  performed  using  the  large  matrix  utilities; 


[PG] 

t'PN] 


pn 

[PN]  +  p*25]T[PM:j 


These  operations  require  the  use  of  two  scratch  matrix  entities  for  the  partitions  of  the  PG  matrix  <Vhen 
both  kgg  and  PG  are  reduced,  the  scratch  partition  matrices  are  shared. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Engineering  Application  Module:  GTLCAD 

Entry  Point:  GTLQAD 

Purpose: 

lb  assemble  ihe  current  static  applied  loads  matrix  for  any  statics  subcases  in  the  current  boundary 
condition. 


MAPOL  Calling  Sequence: 

CAT.L  QTI.OAD  (  NITER,  BC,  GSIZE,  BCSPDT(BC),  GLBDE3 ,  SMPLOD,  [uPTHVT]  , 
[DP6RVI] ,  [PG] ,  OGRIDLOD  ) ; 


NITER 

BC 

G3IZS 

BGEDT(BC) 

GLIDES 

SMPLOD 

taPTOVI] 

[DPGKVI] 

[PG] 

QGBIDLOD 

Application  Calling  Sequence: 
None 


Design  iteration  number  (Integer,  Input) 

Boundary  condition  identification  number  (Integer,  Input) 

The  size  of  the  structural  set  (Integer,  Input) 

Relation  of  basic  grid  point  coordinate  data  (Input) 

Relation  of  global  design  variables  (InpuO 
Unstructured  entity  of  simple  load  vector  information  (Input) 
Matrix  entity  containing  the  thermal  load  sensitivities  (Input) 
Matrix  entity  containing  the  gravity  load  sensitivities  (Input) 
The  matrix  yf  applied  loads  in  the  global  structural  set  (Output) 
Relation  of  loads  on  structural  grid  points.  (Ou  tput) 


Method: 

The  casa  relation  tuples  for  the  current  boundary  condition  are  brought  into  memory  to  obtain  the 
mechanical,  thermal  and/or  gravity  simple  load  identification  numbers  for  each  3TATICS  discipline. 
The  LOAD  bulk  data  relation  is  also  read  into  memory  to  process  combined  simple  loads  requests.  Finally, 
the  smplod  data  are  l  ead  to  determine  the  number  and  types  of  each  simple  load  defined  in  the  bulk 
data  packet.  The  PG  matrix  is  flushed  and  initialized  prior  to  the  start  of  the  loads  assembly  loop.  This 
loop  consists  of  a  search  to  determine  if  the  load  case  is 

(1)  a  simple  mechanical  load 

(2)  a  simple  gravity  load 

(3)  a  simple  thermal  load 

(4)  e,  combination  of  mechanical  and/or  gravity  loads 

The  column  of  the  PG  matrix  associated  with  each  right-hand  side  is  assembled  using  the  SMPLOD  (and 
LOM))  data.  The  thermal  and  gravity  loads  are  special  in  that  the  GLBDES  information  must  be  retrieved 
in  order  to  assemble  the  loads  representing  the  current  design.  The  case  where  no  design  variables  are 
defined  does  not  represent  a  special  case,  however,  since  the  DPVRGI  and  DPTHGI  entities  always  include 
terms  representing  the  "zeroth"  design  variable.  Once  all  the  STATICS  cases  have  been  processed,  the 
module  terminates. 
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Desien  Requirements: 

1.  The  module  assumes  that  at  least  one  static  load  case  is  defined  in  the  case  relation  for  the  current 
boundary  condition. 

2.  The  SMPLOD  entity  from  the  LODGES  module  must  exist  as  must  the  DPVRGI  and  DPTHGX  gravity  and 
thermal  load  sensitivity  matrices. 

Error  Conditions: 

1.  No  simple  loads  are  defined  in  the  t’MPLOD  entity 
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Engineering  Application  Module:  IFP 

Entry  Point:  IFP 

Purpose: 

lb  process  the  Bulk  Data  Pocket  and  to  load  the  input  data  to  the  data  base.  Also,  to  compute  the  external 
coordinate  system  transformation  matrices  and  to  create  the  basic  grid  point  data. 

MAPOL  Calling  Sequence: 

CALL  IFP  (  GSIZEB  )  ; 

gsizeb  The  size  of  the  structural  set  (Integer,  Output) 

Application  Calling  Sequence: 

None 

Method: 

The  Input  File  Processor  module  performs  several  tasks  to  initialize  the  execution  of  ASTROS  procedure. 
It  begins  by  setting  the  titling  information  for  the  IFP  bulk  data  echo  (should  that  option  be  selected). 

Following  these  tasks,  the  module  continues  with  the  interpretation  of  the  bulk  data  packet  of  the  input 
stream.  This  packet  resides  on  an  unstructured  entity  called  &BKDTT  KT  which  is  loaded  by  the  executive 
routine  PREPAS  during  the  interpretation  of  the  input  data  stream.  The  IFP  module  proceeds  in  two 
phases.  In  the  first  phase,  the  bulk  data  are  read,  expanded  from  free  to  fixed  format  and  sorted  on  the 
first  three  fields  of  each  bulk  data  entiy.  If  an  unsorted  echo  is  requested,  that  echo  is  performed  as  the 
sbkdtpkt  entity  is  read.  If  a  sorted  echo  is  desired,  it  is  performed  after  the  expansion  and  sort  has 
taken  place.  In  either  case,  the  bulk  data  is  sorted  by  the  IFP  module.  The  resultant  data  are  stored  on 
one  or  more  scratch  unstructured  entities  depending  on  how  many  passes  must  be  performed  to 
accomplish  the  sort  in  the  available  memory.  If  all  the  bulk  data  fits  into  open  core,  only  a  single  scratch 
file  is  required. 

For  the  MODEL  punch  option  request,  the  expanded  and  sorted  input  Bulk  Data  entries  are  divided  into 
following  categories: 

(1)  element  definition  entries  (e.g.  char) 

(2)  property  definition  entries  (e.g.  pbar) 

(3)  design  variable  linking  and  design  constraint  definition  entries  (e.g.  deseim,  desvarp,  DBSVARS 
and  DCONVMM,  DCONxxx) 

(4)  the  rest  of  the  Bulk  Data 

Those  entries  in  categories  (1),  (2)  and  (4)  are  stored  in  corresponding  unstructured  entities  for  use  in 
module  DESPDNCH.  Tho  se  in  category  (3)  are  not  saved  for  DESPUNCH,  since  it  will  output  aMODEL  without 
the  design  entries. 

The  second  phase  of  the  bulk  data  interpretation  proceeds  based  on  the  sorted  bulk  data  from  the 
expansion  phase.  This  phase  begins  by  reading  the  first  bulk  data  entry  in  the  sorted  list  and  locating 
its  bulk  data  template  in  the  set  of  templates  stored  on  the  system  data  base  by  the  SYSGEN  program. 
This  template  defines  the  card  field  labels,  the  field  variable  type,  the  field  default  value:  the  field  error 
checks  and  information  on  where  to  load  the  field  into  the  data  base  loading  array.  The  template  is 
compiled  once  and  all  like  bulk  data  entries  are  processed  together.  Any  user  input  errors  that  are 
detected  -ire  flagged  with  a  message  indicating  the  field  that  is  in  error  and  whether  the  error  consists 
of  an  illegal  data  type  (i.e,  an  integer  value  in  a  real  field)  or  of  an  illegal  value  for  the  given  field  (i.e., 
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a  negative  element  identification  number).  Note  that  the  iff  module  is  only  checking  errors  on  a  single 
bulk  data  entry  and  does  not  perform  any  inter-entry  compatibility  checks. 

This  process  is  then  repeated  for  each  different  bulk  data  entry  type  in  the  sorted  list  of  bulk  data  entries. 
If  any  errors  have  occured,  the  module  terminates  the  ASTROS  execution.  As  a  final  two  steps,  the  IffP 
module  performs  calls  to  the  MK3MAT,  mkbgpd  and  MRUSET  submodules  to  create  the  transformation 
matrices  for  any  external  coordinate  systems,  to  generate  the  basic  grid  point  data  and  to  make  an  error 
checking  pass  over  the  structural  set  definitions.  These  three  tasks  are  not  explicitly  part  of  the  IFP 
module  but  are  so  basic  to  every  execution  that  they  cannot  properly  be  considered  MAPOL  engineering 
application  modules.  Any  errors  resulting  in  these  two  tasks  will  also  cause  tne  run  to  terminate  with 
the  appropriate  error  messages. 

Design  Requirements: 

None 

Error  Conditions: 

1.  User  bulk  data  errors  are  flagged  and  cause  program  termination. 

2.  Inconsistent  or  illegal  coordinate  system  definitions. 

3.  Illegal  grid/scalar  and/or  extra  point  definitions. 

4.  Illegal  structural  set  definitions  in  the  model. 
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Engineering  Application  Module:  INERTIA 
Entry  Point:  INRTIA 


Tb  compute  the  rigid  body  accelerations  for  statics  analyses  with  inertia  reliei. 

MAPOL  Calling  Sequence: 

CALL  INERTIA  {  [LHS (BC) ] ,  [RHS (3C) 3 ,  [AR]  > ; 

[LBS  (BC)  ]  Rigid  body  reduced  mass  matrix  (Input) 

[RSS  (BC)  ]  Applied  load  vector  reduced  to  the  r-set  (Input) 

[AR]  Matrix  of  acceleration  vectors  (Output) 

Application  Calling  Sequence: 

None 

Method: 

Matrices  LHS  and  RHS  are  read  into  memoiy  and  AR  is  computed  by  solving  [LHS]  [AR]  **  [RES] 
Design  Requirements: 

1.  There  must  be  an  r-set  and  the  reductions  to  the  r-set  must  have  been  performed. 

Error  Conditions: 

1.  The  LHS  matrix  is  singular. 


Engineering  Application  Module:  ITERINIT 

Entry  Point:  ITINIT 

Purpose: 

Initializes  the  const  relation  for  the  current  iteration. 

MAPOL  Calling  Sequence: 

CALL  ZTERINIT  (  NITER,  CONST  ) ; 

niter  Design  iteration  number.  (Integer,  Input) 

const  Relation  of  design  constraints.  (Input  and  Output) 

Application  Calling  Sequence: 

None 

Method: 

This  module  must  be  called  at  the  top  of  each  design  iteration  loop.  Its  function  is  twofold:  1)  to  set  the 
iteration  number  page  header  into  SUBTITLE  (88 : )  in  the  /O0TPT2/  common  and  2)  to  reset  the  CONST 
relation  on  restart  runs. 

Each  page  of  output  during  the  design  iterations  is  labeled  in  the  SUBTITLE  line  with  the  iteration 
number.  It  is  this  module  that  sets  that  part  of  the  subtitle  line  that  contains  that  information. 

The  CONST  relation  is  opened  and,  if  not  empty,  a  conditioned  retrieval  is  done  to  see  if  any  entries  exist 
with  '  iteration  number  greater  than  or  equal  to  the  current  NITER.  If  so,  the  CONST  relation  entries 
with  niter  values  less  than  the  current  NITER  are  copied  to  a  scratch  const  relation,  the  scratch  name 
is  exchanged  for  the  old  const  name  and  the  scratch  entity  (now  pointing  to  the  original  CONST)  is 
destroyed.  Thus,  all  entries  with  niter  values  associated  with  iterations  that  have  not  yet  occurred  are 
flushed.  This  resetting  of  the  CONST  relation  is  done  so  that  ASTROS  can  be  restarted  at  a  previous 
design  iteration  merely  by  setting  the  value  of  NITER  in  the  MAPOL  sequence  back  to  the  desired 
starting  iteration  number. 

If  const  is  empty  or  if  no  restart  actions  are  required,  CONST  is  closed  and  the  module  terminates 
without  action. 

Design  Requirements: 

1.  ITERINIT  is  one  of  the  few  application  modules  that  is  allowed  to  touch  the  TITLE,  subtitle  and 
label  entries  of  the  /  OUTPT2/  common  beyond  the  72nd  character.  While  applications  may  set  the  first 
72  characters  with  the  input  TITLE,  etc. ,  generally  only  the  system  may  modify  them  beyond  that.  These 
labels  are  used  by  UTPAGE. 

Error  Conditions: 

None 
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Engineering  Application  Module:  LAMINCON 

Entry  Point:  LAMCON 

Purposg: 

To  evaluate  composite  laminate  constraints  defined  on  DCONLRM,  DCOKl&a?  and  DCCNEMN  bulk  data 
entries. 


MAPOL  Calling  Sequence: 

m—  Hi  •■ILIUM  ■!'!  fci— 

Oii  LAMINCON  {  NITER,  NDV,  PCONLAM,  DCONIMN,  DCONSMN,  TFINED ,  ©LBDES, 
LOCLVAR,  [ETHANS] ,  CONST  ) ; 


NITER 

NDV 

d  cgnlam 

DCONLMN 

KCONESffil 

TFIXED 

©LBDES 

LOCLVAR 

[ETHANS] 

CON3T 


Design  iteration  number.  (Integer,  Input) 

The  number  of  global  design  variables.  (Integer,  Input) 

The  relation  containing  the  DCONLAS4  entries.  (Input) 

The  relation  containing  the  DCONXMN  entries.  (Input) 

The  relation  containing  the  DCONE8JN  entries.  (Input) 

Relation  of  fixed  thicknesses  of  undesigned  layers  of  designed  composite 
elements  (Output) 

Relation  of  global  design  variables.  (Input) 

Relation  containing  the  relationship  between  local  variables  and  global 
variables  in  the  design  problem.  (Input) 

The  design  variable  linking  matrix.  (Input) 

Relation  of  constraint  values.  (Output) 


Application  Calling  Sequence: 
None 


Method: 

The  LAMINCON  module  begins  by  checking  if  the  DCOHjooc  entities  contain  any  entries.  If  there  are  any 
entries,  they  are  considered  to  be  design  constraints  and  are  imposed  (computed).  Ib  set  up  for  the 
computations,  the  local  design  variable  data,  elemlist  and  ELXLIST  data  are  read  into  memory.  Then 
each  type  of  constraint  is  processed  in  the  order:  ply  minimum  gauge,  laminate  minimum  gauge  and 
laminate  composition.  As  each  constraint  is  computed,  it  is  stored  to  the  const  relation  The  T2IEED 
relation  contains  the  thicknesses  of  all  undesigned  layers  of  composite  elements  and  is  used  in  the 
evaluation  of  these  constraints  to  determine  the  thicknesses  of  layers  defining  either  the  ply  or  the 
laminate. 


Design  Requirements: 

None 

Error  Conditions: 

1.  Missing  PLILIST  or  elemlist  data  referenced  on  DCONxxx  entries 

2.  Ply  or  laminate  definitions  that  include  only  undesigned  layers. 
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Enginesnng  Application  Module:  LAMINSNS 

Entry  Point:  LAMSN3 

Purpose: 

Tb  evaluate  the  sensitivities  of  composite  laminate  constraints  defined  on  DCONLAM,  DCONIMN  and 
dconpmn  bulk  data  entries. 


MAPOL  Calling  Sequence: 

CALL  LAMINSNS  {  NITER,  NDV,  GLBDES ,  LOCLVAR,  [PTRANS]  ,  CONST,  [AMAT]  ); 


NITER 

Design  iteration  number.  (Integer,  Input) 

NDV 

The  number  of  global  design  variables.  (Integer,  Input) 

GLBDES 

Relation  of  global  design  variables.  (Input) 

LOCLV'AR 

Relation  containing  the  relationship  between  local  variables  and  global 
variables  in  the  design  problem.  (Input) 

[RTPwANSj 

The  design  variable  linking  matrix.  (Input) 

CONST 

Relation  of  constraint  values.  (Input) 

[AMAT] 

Matrix  of  constraint  sensitivities.  (Output) 

Application  Calling  Sequence: 

None 

Method: 

TheLMitNSNS  module  begins  by  checking  the  CONST  relation  to  see  if  any  of  the  active  constraints  are 
DCQKL&M,DCONS&N  or  dconimn.  These  constraint  types  ars  processed  in  this  module  if  any  are  active. 

If  any  active  laminate  constraints  are  present,  their  sensitivities  are  computed  from  the  data  in  the 
CONST  relation  and  the  [PTKANS]  matrix  of  sensitivities.  The  format  of  tho  LOCLVAE.  and  [FTRANS] 
data  are  such  that,  for  each  row  in  LOCLV&R,  the  corresponding  column  in  [PTRANS3  is  the  sensitivity 
of  the  local  design  variable. 


These  are  the  constituents  of  the  derivative  computations.  The  appropriate  columns  ars  summed  and 
combined  with  scale  factors  such  as  the  current  thickness  and  allowable  to  compute  each  of  the  constraint 
derivatives. 


For  ply  and  laminate  minimum  gauges,  the  constraint  derivative  is  computed  as: 


6g 

r$v 


where 


j_  V  ** 

-in  ,  3V 
1=1 


ply  or  laminate  minimum  gauge 
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nply  =  number  of  designed  plies  defining  the  ply  or  laminate 


For  laminate  composition  constraints,  the  constraint  derivatives  are  different  depending  on  whether 
upper  or  lower  bound  constraint  is  imposed:  *  " 


Bgupper 

Bv 


npp 
tlam  y. 
i-1 


Bv 


npl 

tply  X 
7=1 


BtUun, 

Bv 


B&lower  _  1 

"  tlm 

where 


npl 
tlam.  X 
7=1 


Btlam, 

Bv 


~  tply 


X 


«=1 


&ply i 


than  =  current  laminate  thickness 
tply  =  current  ply  thickness 
npp  =  number  of  layers  in  the  current  ply 
npl  =  number  of  layers  in  the  current  laminate 
Design  Requirements: 

None 


Error  Conditions: 


I 
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Engineering  Application  Module:  LODGEN 


Entry  Point:  LODGEN 


Purpose: 

Tb  assemble  the  simple  load  vectors  and  simple  load  sensitivities  for  all  applied  loads  in  the  Bulk  Data 
packet. 


MAPOL  Calling  Sequence: 

CMi  LCDGEN  (  GSI2SB,  GLBDES,  DVCT,  DVSIZE,  GMMCT,  DMVT ,  TEIM,  TREF,  SMPLOD, 
[DPTHVTj ,  [DPGRVX]  ) ; 


3SIZEB 

GLBDES 

DVCT 

DVSIZE 

GMMCT 

DMVT 

TEI24 

TREF 

SMPLOD 

[DFTKVI3 

[DPQRVX] 


Length  of  the  g-set  vectors  (Integer,  Input) 

Relation  of  global  design  variables  (Input) 

Relation  containing  the  data  required  for  the  assembly  of  the  design  sensi¬ 
tivity  matrices  (Input) 

Unstructured  entity  containing  memory  allocation  information  on  the 
DVCT  relation  (Input) 

Relation  containing  connectivity  data  for  the  dmvi  sensitivity  matrix 
(Input) 

Unstructured  entity  containing  the  mass  design  sensitivity 

Unstructured  entity  containing  the  element  thermal  load  partitions 
(Input) 

Unstructured  entity  containing  the  element  reference  temperature  (Input) 
Unstructured  entity  of  simple  load  vector  information  (Output) 

Matrix  entity  containing  the  thermal  load  sensitivities  (Output) 

Matrix  entity  containing  the  gravity  load  sensitivities  (Output) 


Application  Calling  Sequence: 
None 


Method: 

The  module  begins  with  a  call  to  subroutine  LDCHK  which  performs  extensive  error  checking  on  the  bulk 
data  and  solution  control  commands  related  to  applied  loads  and  performs  bookkeeping  tasks  prior  to 
the  computation  of  the  simple  loads.  Control  is  then  returned  to  LODGEN  and  cstm  and  BGPDT  data  are 
read  into  core.  A  loop  on  the  number  of  unique  external  load  ID’s  is  then  begun.  Calls  to  PCONST  and 
PFOLOft'  place  mechanical  loads  bulk  data  information  into  a  gsize  loads  vector.  This  vector  is  then 
written  to  the  smplod  unstructured  entity  and  the  process  is  repeated  for  the  remaining  external  loads. 
If  there  are  thermal  loads,  a  call  to  TfiRMLS/D  creates  columns  of  the  DPTHGI  matrix  based  on  element 
thermal  matrices  and  temperature  data.  If  there  are  gravity  leads,  a  call  to  GRAVTS/D  constructs 
acceleration  vectors  and  then  computes  DFVRGI  columns  based  on  the  acceleration  vectors  and  the  DMVI 
unstructured  entity.  The  DVCT,  TELH  and  TREF  entities  are  purged  and  control  is  returned  to  the 
executive. 
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Design  Requirements: 

1.  For  the  general  case,  this  should  be  the  last  preface  module  because  it  may  recjuire  inputs  from  EMG 
and  EM&l. 

Error  Conditions: 

None 
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Engineering  Application  Module:  MAKDFU 
Entry  Point:  MAKDFU 


Purpose: 

lb  assemble  the  sensitivities  to  the  displacements  of  active  stress  and  displacement  constraints  in  the 


current  active  boundary  condition. 

MAPOL  Calling  Sequence: 

CALL  MAKDFU  (  NITER,  BC,  GSIZEB,  [SMAT] ,  [GLBSIG] ,  CONST,  [DFDU] , 

ACTUAGG,  SOB  ) ; 

NITER 

Design  iteration  number  (Integer,  Input) 

BC 

Boundary  condition  identification  number  (Integer,  Input) 

GSIZEB 

The  size  of  the  structural  set  (Integer,  Input) 

[SMAT] 

Matrix  entity  containing  the  sensitivity  of  the  stress  and  strain  compo¬ 
nents  to  the  global  displacements  (Input) 

[GLBSIG] 

Matrix  of  stress/strain  components  for  all  the  applied  stress  constraints 
for  the  current  boundary  condition  (Input) 

CONST 

Relation  of  constraint  values  (Input) 

[DEDU] 

Matrix  containing  the  sensitivities  of  active  displacement  and/or  stress- 
strain  constraints  to  the  displacements  (Output) 

ACTUAGG 

Logical  flag  to  indicate  whether  any  dfdu  terms  exist  (Logical,  Output) 

SUB 

An  optional  flag  which  indicates  whether  statics  or  static  aeroelasticity  is 
associated  with  the  constraints  in  this  call.The  discipline  flag 
=  0  if  STATICS 

=  subscript  identifier,  sub,  of  the  aeroelastic  subcases  if  SAERO 
(Integer,  Input) 

Application  Calling  Sequence: 
None 


Method: 

For  the  current  active  boundary  condition,  the  MAKDFU  module  begins  by  processing  the  active  displace¬ 
ment  constraints.  The  CONST  relation  is  queried  for  all  active  displacement  constraints  (CTY5E®3).  Each 
tuple  that  qualifies  the  active  condition  is  processed  using  the  fnum  attribute  to  position  to  the 
appropriate  location  within  the  DCENT  entity.  The  dcent  terms  are  loaded  in  the  dfdu  matrix  in  the 
order  that  active  displacement  constraints  are  encountered  in  the  const  relation.  Constraints  are 
evaluated  for  each  load  condition  within  the  active  boundary  condition  in  constraint  type  order.  The 
DFDU  matrix  is  thus  also  formed  in  this  order  but  the  inactive  constraints  are  ignored. 

After  processing  the  active  displacement  constraints  (if  any),  the  makdfu  module  processes  the  active 
stress/strain  constraints.  The  CONST  relation  is  conditioned  to  retrieve  the  active  stress  and/or  principal 
strain  constraints  (ctype’s  4,  5  and  6).  For  each  active  constraint,  the  current  boundary  condition 
number  and  the  load  condition  number  (stored  on  the  CONST  relation  in  the  SCEVAL  module)  are  used 
to  determine  the  column  number  of  the  SKAT  matrix  that  holds  the  sensitivity  of  the  current  stress  term 
to  the  displacements.  Having  recovered  the  SMAT  columns  for  the  current  active  constraint,  the  DFDU 
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terns  are  computed  based  on  the  element  type  and  constraint  type.  Where  the  sensitivity  is  a  furrfon 
of  the  stresg/strain  values,  the  appropriate  rows  of  tho  uasii  column  ass^S  “th'tho “urrert 
boundary  cond.tmndoad  condrtion/diecipline  are  retrieved  for  nse  in  tho  compSons 

Design  Requirements: 

None 


Error  Conditions: 


Engineering  Application  Module:  MAKDFV 
Entry  Point:  MAKDBV 


Purpose: 

*— ama  Amimn  n 

lb  assemble  the  sensitivities  of  active  thickness  constraints. 

MAPQL  Calling  Sequence: 

CAIiL  MAEDFV  {  NITER,  NDV,  [PHI NT]  ,  [PMAXT]  ,  CONST,  [AMAT]  )  ; 

niter  Design  iteration  number  (Integer,  Input) 

ndv  The  number  of  global  design  variables  (Integer,  Input) 

[PMTtsfT]  Matrix  entity  containing  the  minimum  thickness  constraint  sensitivities 

(Input) 

[PMAXT3  Matrix  entity  containing  the  maximum  thickness  constraint  sensitivities 

(Input) 

const  Relation  of  constraint  values  (Input) 

[AMAT]  The  matrix  of  constraint  sensitivities  to  the  global  design  variables 

(Output) 

Application  Calling  Sequence: 

None 

Method: 

The  M&KDFV  module  begins  by  determining  if  any  active  thickness  constraints  exist  for  this  design 
iteration.  The  CONST  relation  is  conditioned  to  retrieve  active  minimum  and  maximum  thickness 
constraints.  If  any  active  constraints  are  found,  they  are  processed  in  the  order  recovered  from  the  CONST 
relation;  that  is,  active  minimum  thickness  constraints  followed  by  active  maximum  thickness  con¬ 
straints.  Since  the  constraint  sensitivities  are  functions  of  the  current  local  variable  value  when  they 
are  controlled  by  move  limits  rather  than  gauge  limits,  the  execution  of  the  module  proceeds  with  the 
calculation  of  all  the  individual  layer  thicknesses  for  all  the  elements  designed  by  shape  functions.  Since 
i  ms  limits  are  considered  to  be  desirable  in  the  vast  majority  of  cases  and  because  there  is  no  reliable 
way  to  determine  before-hand  if  any  particular  active  constraint  is  move  limit  controlled,  the  local 
variables  are  always  computed  in  this  module.  The  ftrans  matrix,  prepared  in  the  M&kest  module  is 
used  to  evaluate  these  thicknesses: 

It)  =  [PTRANS]T(v) 

After  the  local  variables  have  been  computed,  the  loclvar  relation  (also  built  in  the  MAKEST  module) 
is  used  to  determine  the  current  total  thickness  for  a  layered  composite  element.  The  VFIXED  entity 
gives  that  portion  of  the  thickness  cf  composite  elements  that  is  not  designed.  The  sensitivities  of  the 
thickness  constraints  are  essentially  the  appropriate  column  of  the  PMINT  or  PMAXT  matrix.  The  column 
is  identified  by  the  PNOM  attribute  of  the  const  relation.  If  the  particular  local  variable  constraint  is 
controlled  by  move  limits,  however,  the  sensitivity  becomes  a  function  of  the  current  thickness  and  must 
be  adjusted  accordingly.  This  applies  only  to  minimum  gauge  constraints,  however,  since  move  limits 
ere  not  applied  to  maximum  thickness  constraints.  The  resulting  constraint  sensitivities  are  loaded,  in 
the  order  processed,  onto  the  AMAT  matrix. 
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Design  Requirements: 

1.  The  move  limit  that  is  passed  into  this  routine  must  match  the  value  used  to  evaluate  the  constraints 
in  the  TOEVAL  module.  If  not.  the  constraint  sensitivities  will  be  in  error  with  no  warning  given. 

Error  Conditions: 

1.  The  move  limit  must  be  greater  than  1.0  if  it  is  imposed. 


Engineering  Application  Module:  MAKDVU 
Entry  Point:  MAKDVU 


Purpose: 

lb  multiply  the  stiffness  or  mass  design  sensitivities  by  the  active  displacements  or  accelerations. 
MAPOL  Calling  Sequence: 

CALL  MAKDVU  (  NITER,  NBV,  GLBDES,  [UGA]  ,  [DRUG],  GMKCT,  DKVI  ); 


NITER 

NDV 

GLBDES 

[UGA] 

[DRUG] 

GMKCT 

DKVI 


Design  iteration  number  (Integer,  Input) 

Number  of  design  variables  (Integer,  Input) 

Relation  of  global  design  variables  (Input) 

Matrix  of  "active"  displacements  or  accelerations  for  the  current  boundary 
condition  (Input) 

The  product  of  the  design  sensitivity  matrices  and  the  active  displace¬ 
ment/acceleration  vectors  (Output) 

Relation  containing  connectivity  data  for  the  DKVI  sensitivity  matrix 
(Input) 

Unstructured  entity  containing  the  stiffness  or  mass  design  sensitivity 
matrix  in  a  highly  compressed  format  (Input) 


Application  Calling  Sequence: 
None 


Method: 

This  is  a  utility  module  that  performs  a  matrix  multiplication  of  a  g-set  matrix  of  displacements  or 
accelerations  and  the  g-set  sized  design  sensitivities  DKVI  or  DMVI  entities  that  are  the  NDV  g  x  g  design 
sensitivity  matrices  stored  in  a  highly  compressed  format. 

The  module  first  reads  in  design  variable  information  (id  and  value)  and  then  space  is  reserved  for  the 
maximum  DKVI  record.  A  determination  is  made  as  to  how  many  columns  of  uga  and  DRUG  can  be  held 
in  core  simultaneously.  Spill  logic  is  used  if  not  all  the  columns  can  be  processed  simultaneously. 
Columns  of  UGA  are  read  into  core  and  a  loop  on  the  number  of  design  variables  is  made  to  calculate  the 
columns  of  the  DRUG  matrix.  Care  is  taken  to  write  null  columns  when  a  particular  design  variable  has 
no  DKVI  entries.  The  UNMTML  subroutine  is  called  by  MAKDVD  to  multiply  the  unstructured  data  and  the 
response  vector. 

Design  Requirements: 

1.  The  format  of  the  DKVT/GMKCT  inputs  is  assumed  to  parallel  the  structure  of  those  entities  output 
from  EMA1. 

Error  Conditions: 

None 
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Engineering  Application  Module:  makest 
Entry  Point:  MAKEST 


Purpose: 

Tb  generate  the  element  summary  relational  entities  for  all  structural  elements.  Also,  to  determine  the 
design  variable  linking  and  generate  sensitivities  for  any  thickness  constraints. 

MAPOL  Calling  Sequence: 

CALL  MAKEST  (  NDV,  GLBDES ,  [PTRANS],  [ES4IHT]  ,  [PMAXT] ,  LOCLVAR, 

TFIXED,  DESLINK  ); 

The  number  of  global  design  variables  (Integer,  Output) 

Relation  of  global  design  variables  (Output) 

The  design  variable  linking  matrix  (Output) 

Matrix  entity  containing  the  minimum  thickness  constraint  sensitivities 
(Output) 

Matrix  entity  containing  the  maximum  thickness  constraint  sensitivities 
(Output) 

Relation  containing  the  relationship  between  local  variables  and  global 
variables  in  the  design  problem  (Output) 

Relation  of  fixed  thicknesses  of  undesigned  layers  of  designed  composite 
elements  (Output) 

Relation  of  design  variable  connectivity  from  MAKEST  module  containing 
one  record  for  each  global  design  variable  connected  to  each  local  vari¬ 
able.  (Input) 

Application  Calling  Sequence: 

None 

Method: 

The  makest  module  performs  the  first  phase  of  the  structural  element  preface  operations  with  the  EM8 
module  performing  the  second  phase.  The  first  action  of  the  module  is  to  perform  the  uniqueness  error 
checks  on  the  element  bulk  data  as  stored  on  the  data  base  by  the  IFP  module.  These  checks  ensure 
that  all  property  entries  have  unique  identification  numbers  within  each  property  typo  (with  the 
exception  of  the  PCCMPi  entries  where  duplicate  ID’s  signify  different  composite  layers).  Also,  unique 
identification  numbers  for  the  MATi  entries  are  enforced  across  all  MATi  types.  The  MAKEST  module  then 
performs  the  imtial  processing  of  the  design  variable  linking  in  the  PREDES  module.  The  GLBDES  relation 
is  set  up  in  memory  with  several  columns  to  be  filled  in  as  the  design  variable  linking  is  continued  later 
in  the  module.  If  there  are  design  variables  defined  in  the  bulk  data,  the  number  of  global  design 
variables,  NDV,  is  determined  for  output  to  the  MAPOL  sequence  and  a  number  of  scratch  and  hidden 
entities  are  opened  to  prepare  for  the  design  variable  linking  task  performed  in  this  module. 

The  MAKEST  module  continues  by  reading  in  the  bgpdt  data  and  initializing  the  PTRANS,  EMINT,  and 
FMAXT  matrix  columns  that  are  built  on  the  fly  in  the  element  dependent  routines.  The  module  then 
calls  each  element  dependent  routine  in  turn.  The  order  in  which  these  submodules  are  called  is  very 
important  in  that  it  provides  an  implicit  order  for  the  MAKEST,  EMG,  SCEVAL,  KDR  and  OFF  modules. 


NDV 

GLBDES 

[PTRANS] 

[PMINT] 

[SMAXT] 

LOCLVAR 

TFIXED 

DESLINK 
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That  order  is  alphabetical  by  connectivity  bulk  data  entry  and  results  in  the  following  sequence: 

(1)  Bar  elements 

(2)  Scalar  spring  elements 

(3)  Linear  isoparametric  hexahedral  elements 

(4)  Quadratic  isoparametric  hexahedral  elements 

(5)  Cubic  isoparametric  hexahedral  elements 

(6)  Scalar  mass  elements 

(7)  General  concentrated  mass  elements 

(8)  Rigid  body  form  of  the  concentrated  mass  elements 

(9)  Isoparametric  quadrilateral  membrane  elements 

(10)  Quadrilateral  bending  plate  elements 

(11)  Rod  elements 

(12)  Shear  panels 

(13)  Triangular  bending  plate  elements 

(14)  Triangular  membrane  elements 

Within  each  element  dependent  routine,  the  xxxEST  relation  for  the  element  is  opened  and  flushed.  If 
design  variables  exist  in  the  model,  the  ELI  ST,  PLIST  and  shape  entries  associated  with  this  element 
type  (if  the  element  can  be  designed)  are  opened  and  read  into  memory  for  use  in  the  design  variable 
linking.  Then  the  connectivity  relation  for  the  element  is  opened  and  the  main  processing  loop  begins. 
Each  tuple  is  read,  the  grid  point  references  are  resolved  into  internal  sequence  numbers  and  coordi¬ 
nates,  the  property  entry  is  found  from  the  proper  property  relation(s)  and  the  EST  relation  tuple  is 
formed  in  memory.  Numerous  checks  on  the  existence  of  grid  points,  property  entries  and  the  uniqueness 
of  the  element  identification  number  within  each  element  type  are  performed. 

Finally,  if  there  are  design  variables,  the  DESCHK  submodule  is  called  to  determine  whether  the  element 
is  linked  to  a  design  variable.  The  deschk  utility  searches  the  in-core  glbdes,  ELIST,  plist  and/or 
SHAPE  data  and  determines  if  the  current  element  is  designed.  Also,  the  final  attributes  of  the  glbdes 
relation  for  physical  and  shape  function  linking  are  completed.  The  module  performs  error  checks  to 
ensure  that  the  rules  for  design  variable  linking  are  satisfied  for  each  particular  global  design  variable 
and  element. 

On  return  to  the  element  EST  routine,  the  loclvar,  PTRANS,  pmint  and/or  FMAXt  entities  are  built  for 
the  local  design  variable  if  the  element  was  found  by  deschk  to  be  designed.  Finally,  any  restrictions 
on  the  behavior  or  options  for  designed  elements  are  checked  for  and  the  proper  warning  messages 
issued.  For  example,  a  designed  element’s  nonstructural  mass  is  reset  to  zero  with  a  warning  message. 
Finally,  the  constraint  flags,  design  flags  and  thermal  stress  information  are  set.  The  constraint  and 
thermal  stress  attributes  will  be  revised  as  needed  in  the  EMG  module. 
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When  all  the  elements  have  been  processed,  the  EST  relation  for  the  element  type  is  loaded  to  the  data 
base.  Care  is  taken  that  the  final  relation  is  sorted  by  the  element  identification  number.  When  all  the 
element  routines  have  been  called,  the  DESLINK  entity,  which  was  formed  on  the  fly  in  the  element 
routines,  is  loaded  to  the  data  base.  This  entity  contains  the  number  of  and  identification  numbers  for 
each  design  variable  connected  to  each  designed  element.  These  data  are  used  to  generate  the  dvct 
relation  in  the  EMG  module.  All  the  other  design  variable  linking  entities  that  have  been  built  on  the  fly 
are  also  closed.  Any  queued  error  messages  are  dumped  to  the  user  file  and  the  module  terminates. 

Design  Requirements: 

1.  The  basic  connectivity  data  from  the  IFP  module  must  be  available. 

Error  Conditions: 

1.  Numerous  error  checks  are  performed  on  the  consistency  of  the  bulk  data  for  structural  element 
definition  as  well  as  of  element  geometry  and  connectivity. 

2.  Design  variable  linking  errors  are  flagged. 
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Engineering  Application  Module:  MK2GG 
Entry  Point:  MK2GG 


Purpose: 

Interprets  case  control  for  the  current  boundary  condition  and  outputs  the  MJ?QG  and/or  K2GG  matrices 
if  any. 

MAPOL  Calling  Sequence: 

CALL  MK2GG  (  BC,  GSIZEB,  [M2GG]  ,  M2GGFLAG,  [K2GG]  ,  K2GGFLAG  ); 


BC 


Boundary  condition  number.  (Integer,  Input) 


GSIZEB 

[M2GG] 


Number  of  g-set  DOF’s  excluding  any  that  may  have  been  added  on  ear¬ 
lier  iterations  by  GDSL  (Integer,  Input) 

Direct  input  g-set  mass  matrix  for  the  current  BC.  (Optional,  Output) 


M2GGELAG  Flag  indicating  whether  M2GG  was  loaded  with  data  (Optional,  Logical, 

Output) 

[K2GG]  Direct  input  g-set  stiffness  matrix  for  the  current  BC.  (Optional,  Output) 

Flag  indicating  whether  K2GG  was  loaded  with  data  (Optional,  Logical, 
Output) 


Application  Calling  Sequence: 
None 


Method: 

First  the  CASE  relation  is  read  for  the  current  boundary  condition  to  determine  ifM2GG  or  K2GG  matrices 
were  named.  Error  checking  is  performed  to  ensure  that  an  output  matrix  is  passed  to  MK2GG  for  both 
matrices  if  both  are  named  in  CASE.  The  arguments  are  otherwise  optional.  Further,  the  entities  named 
in  case  are  checked  to  ensure  that  they  are  matrices  and  that  they  are  square  and  of  the  proper  row 
and  column  dimensions  (GSIZEB  x  GSIZEB). 

Then  the  named  output  matrix  is  created,  or  if  it  already  exists,  flushed.  The  append  utility  is  used  to 
copy  the  named  entity  onto  the  output  entity. 

Design  Requirements: 

1.  The  dmig  or  DMI  entries  that  may  be  sources  of  the  M2GG  and/or  K2GG  matrices  must  be  processed 
prior  the  the  calling  of  this  module.  Th: i  module  assumes  that  the  named  entities  already  exist. 

Error  Conditions: 

1.  x2gg  entities  do  not  exist. 

2.  x2gg  entities  are  not  matrix  entities 

3.  x2gg  entities  are  not  of  the  proper  dimension. 

4.  All  errors  cause  ASTROS  termination. 
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Engineering  Application  Module:  MKAMAT 


MKftMAT 


lb  assemble  the  constraint  sensitivity  matrix  from  the  sensitivity  matrices  formed  by  MAKDFtr  and  the 
sensitivities  of  the  displacements  for  active  static  load  conditions  in  the  current  active  boundary 
condition. 


JrUL  Calling  sequence: 

CALL  MKAMAT  <  [AMAT]  ,  [FIRST]  ,  [SECOND] ,  PC&,  [PSA]  )  ; 


[AMAT] 


[FIRST] 

[SECOND] 


[PGA] 


Matrix  of  sensitivities  of  the  constraints  to  the  design  variables  (Input 
and  Output) 

Leading  matrix  in  the  multiply  to  obtain  AMAT  (Input) 

Trailing  matrix  in  the  multiply  to  obtain  (Input) 

Unstructured  entity  which  contains  the  unique  subcase  numbers  for  the 
constraints  that  are  active  for  the  boundary  condition.  Only  constraints 
for  the  current  boundary  condition  are  included  in  the  list  (Input) 

Partition  vector  for  active  displacement  vectors  (Input) 


tion  Calling  sequence: 


Method: 

Conceptually,  the  module  multiplies  the  transpose  of  the  first  matrix  times  the  second.  The  data  in 
the  two  matrices  are  determined  based  on  whether  the  gradient  method  or  the  virtual  loads  method  of 
sensitivity  analysis  is  being  employed  (see  Subsection  6,3  of  the  Theoretical  Manual).  The  matrix 
multiply  is  complicated  by  the  fact  that  it  may  be  necessary  to  partition  the  matrices  for  each  subcase 
that  is  active  in  the  boundary  condition. 

The  module  begins  by  reading  the  PCA  and  PGA  information  into  core.  The  number  and  identity  of  the 
active  subcases  is  determined.  If  the  number  is  greater  1 one,  nine  scratch  matrix  entities  are  created 
to  store  intermediate  data,  Aloop  on  the  number  of  active  subcases  then  occurs.  If  it  is  not  the  last  pass 
through  thb  loop,  the  FIRST  matrix  is  partitioned  to  obtain  the  3CV  columns  that  apply  for  the  current 
subcase  and  the  second  matrix  is  partitioned  to  obtain  only  the  columns  that  correspond  to  active 
constraints  for  the  subcase. 

The  algorithm  is  somewhat  more  complicated  than  this  in  that  the  parts  of  the  matrices  that  remain 
after  partitioning  are  renamed  to  FIRST  and  second  so  that  the  partitioning  operation  becomes 
successively  smaller  and  no  partition  is  required  on  the  last  pass  through  the  loop.  The  extracted 
matrices  are  then  multiplied  and  the  resulting  matrix  is  either  AMAT  (when  there  is  only  one  active 
sub  sf-  and  the  AMAT  matrix  was  empty  on  entering  the  module)  or  it  is  appended  to  AMAT.  Once  the 
loop  :s  completed,  any  scratch  matrices  are  destroyed  and  control  is  returned  to  the  executive. 
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Design  Requirements: 

1.  This  module  is  invoked  at  the  end  of  the  boundary  condition  loop  in  the  sensitivity  analysis  portion 
of  the  MAFOL  sequence. 

2.  It  is  called  only  if  there  are  active  stress  and  displacement  constraints  for  the  boundary  condition. 
Error  Conditions: 

None 
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Engineering  Application  Module:  MKUSET 

Entry  Point:  MKiJSET 

Purpose: 

lb  generate  the  structural  set  definition  entity,  USET,  for  each  boundary  condition  and  to  form  the 
partitioning  vectors  and  transformation  matrices  used  in  matrix  reduction, 

MAPOL  Calling  Sequence: 

CALL  MKUSET  (BC,  GSIZEB,  [TS  (BC)  ]  ,  [TMK (BC)  ]  ,  [PGHH (BC) ] ,  []?KSF{BC)  ]  , 

[PFOA(BC) ] ,  [PARL(BC) ] ,  USET(BC)  ) ; 

Boundary  condition  identification  number  (Integer,  Input) 

The  size  of  the  structural  set  (Integer,  Input) 

The  vector  of  enforced  displacements  (Output) 

The  transformation  matrix  for  multipoint  constraints  (Output) 

The  partitioning  vector  splitting  the  structural  degrees  of  freedom  into 
the  independent  and  the  multipoint  constraint  degrees  of  freedom  (Out¬ 
put) 

The  partitioning  vector  splitting  the  independent  degrees  of  freedom  into 
the  free  and  the  single  point  constraint  degrees  of  freedom  (Output) 

The  partitioning  vector  splitting  the  free  degrees  of  freedom  into  the 
analysis  set  and  the  omitted  degress  of  freedom  (Output) 

The  partitioning  vector  splitting  the  analysis  set  degrees  of  freedom  into 
the  i-set  and  the  support  degrees  of  freedom  (Output) 

The  unstructured  entity  defining  structural  sets  (Output) 

Application  Calling  Sequence: 

None 


BC 

GSIZEB 
tys(BC)] 
[TMN  (BC)  ] 
[E’CMN  (BC)  ] 

[PNSF (BC) ] 
[FFOA(BC) ] 
[PARL(BC)] 
USET  (BC) 


Method: 

The  MKUSET  module  performs  four  tasks.  The  first  is  to  build  the  USET  entity  of  structural  set  definition 
masks  for  the  input  boundary  condition.  At  the  same  time,  the  rigid  constraint  matrix,  TMN,  relating  the 
dependent  multipoint  constraint  degrees  of  freedom  to  the  independent  degrees  of  freedom  is  formed. 
Also,  the  vectors  of  enforced  displacements  for  single  point  constraints  are  formed.  Lastly,  the  partition¬ 
ing  vectors  for  the  structural  sets  are  formed. 

The  generation  of  boundary  condition  dependent  subscripted  matrix  entities  requires  that  the  MKuset 
module  be  called  once  for  each  boundary  condition  in  the  Solution  Control  packet.  The  looping  logic  is 
contained  in  the  standard  executive  sequence  rather  than  within  th6  module  itself.  Each  structural 
degree  of  freedom  (DOF)  is  assigned  a  word  in  each  record  of  the  USET  entity  (aerodynamic  degrees  of 
freedom  and  extra  points  are  ignored).  One  record  is  created  for  each  boundary  condition  in  the  Solution 
Control  packet.  The  MKUSET  module  determines  to  which  sets  a  structural  DOF  belongs  and  sets  the 
corresponding  bits  in  the  USET  word  associated  with  that  degree  of  freedom.  That  word  is  the  bitmask 
for  that  degree  of  freedom. 


182 


The  assignment  of  a  bit  position  for  each  structural  set  is  defined  as  shown  below  and  are  stored  in  the 
/BITPOS/  common  block: 


SET 

BIT 

POSITION 

DESCRIPTION 

ux 

16 

Used  for  dynamic  reduction 

UJJP 

17 

UJJ 

18 

UKK 

19 

USB 

20 

Single  point  constraints  (SPC> 

use* 

21 

Permanent  spcs 

UL 

22 

Free  points  left  for  solution 

XJA 

23 

Analysis  set 

UP 

24 

Free  degrees  of  freedom 

TJN 

25 

Independent  degrees  of  freedom 

UG 

26 

Dependent  degrees  of  freedom 

UR 

27 

Support  set  DOF 

UO 

28 

Omitted  (Guyan  Reduction)  DOF 

US 

29 

Unions  of  USB  and  usg  sets 

UM 

30 

Dependent  MPC  DOF 

The  mkoset  module  begins  by  preparing  memory  blocks  for  use  by  the  module  subroutines.  The  BQPDT 
tuples  associated  with  structural  noues  are  brought  into  core  for  use  in  conversion  of  external  identifi¬ 
cation  numbers  to  internal  identification  numbers.  Each  separate  structural  set  is  processed  by  an 
individual  submodule  of  MKUS'^T  with  the  defaulting  for  unspecified  DOF  taking  place  in  the  module 
driver  The  case  relation  is  read  to  determine  the  boundary  condition  definition  for  the  current  boundary 
condition.  The  submodule  UMSET,  responsible  fer  multipoint  constraint  set  definition  also  build  the  TMN 
matrix  while  the  ns  SET  submodule  for  single  point  constraints  builds  the  is  vector.  After  the  USET 
masks  have  been  built  far  the  boundary  condition,  extensive  error  checking  occurs  to  ensure  that  each 
point  is  placed  in  no  more  than  one  dependent  structural  set.  If  no  errors  have  occured,  the  USET  record 
is  written  and  the  associated  partitioning  vectors  are  formed. 

Design  Requirements: 

1.  The  mkuset  module  requires  that  the  CASE  relation  b8  complete  from  the  SOLUTION  module  and  that 
the  Bqpdt  be  formed  either  by  the  BCBGPDT  or  ifp  modules  prior  to  execution. 

Error  Conditions: 

1.  Any  inconsistent  boundary  condition  specifications  are  flagged. 

2.  Any  missing  bulk  data  referenced  by  Solution  Control  is  flagged. 
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Engineering  Application  Module:  NREDUCE 

Entry  Point:  NREDUC 

Purpose: 

lb  reduce  the  symmetric  n-set  stiffness,  mass  or  loads  matrix  to  the  f-set  if  there  are  single  point 
constraints  in  the  boundary  condition. 

MAPOL  Calling  Sequence: 

CAU.  NREDUCE  (  [KNN],  [PN]  ,  [PNSF(BC)],  [YS(BC>],  [KFF],  [KFS] , 

[KSS],  [PF],  EPS]  ); 

Optional  matrix  containing  the  independent  stiffness  or  mass  matrix  to 
be  reduced  (Input) 

Optional  matrix  containing  the  applied  loads  to  be  reduced  (Input) 

The  partitioning  vector  splitting  the  independent  degrees  of  freedom  into 
the  free  and  the  single  point  constraint  degrees  of  freedom  (Input) 

Optional  matrix  containing  the  vector  of  enforced  displacements  (Input) 

Optional  matrix  containing  the  reduced  form  of  KNN  (Output) 

Optional  matrix  containing  the  off-diagonal  partition  of  KFF  (Output) 

Optional  matrix  containing  the  dependent  diagonal  partition  of  KFF  (Out¬ 
put) 

Optional  matrix  containing  the  reduced  form  of  PN  (Output) 

The  load  matrix  partition  for  computation  of  spcforces  (Output) 

Application  Calling  Sequence: 

None 


[KNN] 

[PN] 

[PN3F  (EC)  ] 

[YS (BC) ] 
[KFF] 

[KFS] 

[KSS] 

[PF] 

[PS] 


Method: 

If  the  PN  argument  is  nonblank,  the  module  determines  the  number  of  columns  in  the  loads  matrix. 
Further,  if  the  YS  vector  is  nonblank,  it  is  expanded  to  have  the  proper  number  of  duplicate  columns. 
Having  taken  care  of  the  YS  matrix,  the  module  proceeds  to  check  if  the  KNN  argument  is  nonblank.  If 
so,  and  there  are  no  enforced  displacements,  the  KNN  matrix  is  partitioned  into  KFF  and  KFS  (if  the  KFS 
matrix  is  input).  If  there  are  enforced  displacements,  the  KSS  partition  is  also  saved  if  the  KSS  argument 
is  supplied.  The  module  then  proceeds  to  reduce  the  loads  matrix  if  the  PN  argument,  is  nonblank.  If 
there  are  no  enforced  displacements,  the  matrix  is  simply  partitioned  to  PF.  When  enforced  displace¬ 
ments  are  present,  the  loads  on  the  free  degrees  of  freedom  are  computed  as: 

[PF]  «  [PF]  -  [KFS] [YS] 

The  module  then  terminates. 


184 


Design  Requirements: 


1.  If  there  are  nonzero  enforced  displacements,  the  stiffness  and  loads  reductions  must  be  done 
concurrently  or  the  KFS  partition  must  be  included  in  the  loads  call  as  input. 

2.  The  KjTS  argument  is  always  required  when  YS  is  nonblank. 

Error  Conditions: 

None 
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Engineering  Application  Module:  OFPAEROM 

Entry  Point:  OFPARO 

Purpose: 

This  module  solves  for  the  static  aerc  applied  loads  on  the  aero  boxes  and  for  the  displacements  on  the 
aero  boxes  to  satisfy  the  airdisp  and  tpressure  print/punch  requests.  It  loads  the  oaqrdlod  and 
OAGRDDSP  relation. 


MAPOL  Calling  Sequence: 

CALL  OFPAERCM  {  NITER,  BC,  MINDEX,  SOB,  GSIZE,  GEOMSA,  [GTKG],  [GSTKG],  QDP, 
[AIRFRC (MINDEX) ] ,  [DELTA ( SUB) ] ,  [AICMAT (MINDEX) ] ,  [UAG (BC) ] , 
OAGRDLOD ,  OAGRDDSP  ) ; 


NITER 

BC 

MINDEX 

SUB 

GSIZE 

GECMSA 


[GTKG] 

[GSTKG] 


QDP 

[AIRFRC  (MINDEX)  ] 


[DELTA  (SUB)] 


[AICMAT  (MINDEX)  ] 


[UAG  (BC)  ] 


Design  iteration  number.  (Optional,  Integer,  Input) 

Boundary  condition  number.  (Integer,  Input) 

Mach  number  index  associated  with  the  current  subscript.  (Integer,  Input) 

Current  Mach  number  subscript  number.  (Integer,  Input) 

Number  of  g-set  DOF’s  including  any  that  may  have  been  added  by  GDR. 
(Integer,  Input) 

A  relation  describing  the  aerodynamic  boxes  for  the  steady  aerodynamics 
model.  The  location  of  the  box  centroid,  normal  and  pitch  moment  axis 
are  given.  It  is  used  in  splitting  the  aerodynamics  to  the  structure  and  to 
map  responses  back  to  the  aerodynamic  boxes.  (Input) 

The  matrix  of  splining  coefficients  relating  the  aerodynamic  pressures  to 
forces  at  the  structural  grids.  (Input) 

The  matrix  of  splining  coefficients  relating  the  structural  displacements 
to  the  streamwise  slopes  of  the  aerodynamic  boxes.  (Input) 

Dynamic  pressure  associated  with  the  current  subscript.  (Real,  Input) 

Matrix  containing  the  aerodynamic  forces  for  unit  configuration  parame¬ 
ters  for  the  current  Mach  number  index.  If  both  symmetric  and  antisym¬ 
metric  conditions  exist  for  the  Mach  number,  both  sets  of  configuration 
parameters  will  coexist  in  AIRFRC.  (Input) 

Matrix  containing  the  set  of  configuration  parameters  representing  the 
user  input  fixed  values  and  the  trimmed  unknown  values  for  the  sub  sub¬ 
script’s  trim  cases.  (Input) 

Matrix  containing  the  steady  aerodynamic  influence  coefficients  for  either 
symmetric  or  antisymmetric  Mach  numbers  as  appropriate  for  the  sym¬ 
metry  of  the  cases  in  the  current  boundary  condition.  (Input) 

Matrix  of  static  displacements  for  all  saerq  subcases  in  the  current 
boundary  condition  in  the  order  the  subcases  appear  in  the  CASE  relation. 
(Input) 
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oagrdlod  A  relation  containing  the  rigid,  flexible  correction  and  flexible  forces  and 

pressures  for  each  SAERO  subcase  for  the  trimmed  configuration  parame¬ 
ters.  Outputs  are  for  the  aerodynamic  elements  whose  tpressore  output 
was  requested  in  Solution  Control.  These  constitute  the  loads  of  the 
"trimmed"  state  of  the  configuration.  (Output) 

oagrddsp  A  relation  containing  the  displacements  for  each  SAERO  subcase’s  set  of 

configuration  parameters  for  the  aerodynamic  elements  whose  AIRDISP 
output  was  requested  in  Solution  Control.  These  constitute  the  trimmed 
displacements  of  the  aerodynamic  MODEL.  (Output) 

Application  Calling  Sequence: 

None 

Method: 

The  CASE  relation  is  read  to  obtain  the  list  of  all  SAERO  subcases  for  the  current  boundary  condition. 
The  AIRDISP  and  TPRESSORE  print/punch  requests  are  checked  and  the  module  terrains  ,s  if  no  output 
requests  exist. 

If  output  is  needed,  the  TRIM  relation  is  read  to  obtain  the  subscript  values  of  each  subcase.  Apartitioning 
vector  is  formed  as  the  trim  data  are  searched  to  extract  the  proper  columns  from  the  0AG  matrix  for 
the  subcases  associated  with  the  current  SOB  value.  Then,  for  each  subcase  to  be  processed,  the  particular 
print  and  punch  requests  are  evaluated  and,  in  the  most  general  case,  the  following  are  computed: 

Rigid  Air  Loads: 

=  QDP* [AIRFRC] [DELTA] 

Flexible  Correction  to  the  Rigid  Air  Loads: 

-  QDP*  [AICMAT]  T  [GSTKG]  T  [OAG] 

Total  Applied  Air  Loads: 

=  Rigid  +  Flexible 

Displacements  on  the  aero  boxes 
=  [GTRG]  T  [OAG] 

where  in  each  case  the  [delta]  and  [OAG]  matrices  are  partitioned  to  include  only  the  relevant 
subcases  for  the  current  subscript. 

Finally,  the  scratch  matrices  on  which  these  results  reside  are  read  and  output  to  the  OAGRDLOD  and 
oagrddsp  relations  for  the  loads  and  displacements,  respectively. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Engineering  Application  Module:  ofpaload 
Entry  Point:  OFPALD 


Purpose: 

Solves  for  the  static  aero  applied  loads  and  SPC  forces  to  satisfy  the  print/punch  requests.  The  resultant 
loads  are  written  to  the  OGRIDIiOD  relation. 


MAPOL  Calling  Sequence: 

CALL  OFPALOAD  (  NITER,  BC,  MINDEX,  SUB,  GSIZE,  BGPDT(BC) ,  [GTKG] ,  [GSTKG], 
QDP,  [AIRFRC  (MINDEX)  ]  ,  [DELTA (SUB)  ]  ,  [AICMAT (MINDEX)  ]  , 
[UAG(BC)],  [MGG],  [AAG (BC) ] ,  [KFS] ,  [KSS] ,  [UAF] ,  [XS(BC)], 
[PNSF(BC)],  [PGMN (BC) ] ,  [PFJK]  ,  NGDR,  USET(BC),  OGRIDLOD  ) ; 


NITER 


Design  iteration  number.  (Integer,  Input) 


BC 


Boundary  condition  identification  number  (Integer,  Input) 


MINDEX 


Mach  number  index  for  the  current  subscript  value.  (Integer,  Input) 


SUB 

GSIZE 

BGPDT (BC) 

[GTKG] 

[GSTKG] 

QDP 


Subscript  number  of  SAERO  subcases  considered  in  this  call. 

(Integer,  Input) 

Number  of  degrees  of  freedom  in  the  g-set  including  those  that  may  have 
been  added  by  OR  (Integer,  Input) 

Relation  of  basic  grid  point  data  for  the  boundary  condition  (including 
any  extra  points  and  OR  scalar  points  which  may  be  added  by  the  OR 
module).  (Input) 

The  matrix  of  splining  coefficients  relating  the  aerodynamic  pressures  to 
forces  at  the  structural  grids.  (Input) 

The  matrix  of  splining  coefficients  relating  the  structural  displacements 
to  the  streamwise  slopes  of  the  aerodynamic  boxes.  (Input) 

Dynamic  pressure  associated  with  the  current  subscript.  (Real,  Input) 


[AIRFRC  (MINDEX)  ]  Matrix  containing  the  aerodynamic  forces  for  unit  configuration  parame¬ 
ters  for  the  current  Mach  number  index.  If  both  symmetric  and  antisym¬ 
metric  conditions  exist  for  the  Mach  number,  both  sets  of  configuration 
parameters  will  coexist  in  AIRFRC.  (Input) 

[delta  (SUB)  ]  Matrix  containing  the  set  of  configuration  parameters  representing  the 

user  input  fixed  values  and  the  trimmed  unknown  values  for  the  SUB  sub¬ 
script’s  trim  cases.  (Input) 

[AICMAT  (MINDEX)  ]  Matrix  containing  the  steady  aerodynamic  influence  coefficients  for  either 
symmetric  or  antisymmetric  Mach  numbers  as  appropriate  for  the  sym¬ 
metry  of  the  cases  in  the  current  boundary  condition.  (Input) 

[uag  (BC)  ]  Matrix  of  static  displacements  for  ail  SAERO  subcases  in  the  current 

boundary  condition  in  the  order  the  subcases  appear  in  the  CASE  relation. 
(Input) 

[MGG]  Mass  matrix  in  the  g-set.  (Input) 
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[AAG  (BC)  ] 

[KFS] 

[KSS] 

[OAF] 

[YS (BC) ] 

[PNSF(BC) 

[PGMN (BC) 

[PFJK] 

NGDR 

USST (BC) 

OGRIDLOD 

Application  Calling  Sequence: 

ISL-ne 

Method: 

First  the  case  relation  entries  for  saero  subcases  in  the  current  boundary  condition  are  read.  Then  the 
TRIM  relation  is  read  to  determine  which  subcases  are  associated  with  the  current  subscript  value.  Then 
the  output  LOAD  and  SPCF  print/punch  requests  are  examined  to  see  if  any  further  work  is  needed.  If 
no  print  or  punch  requests  are  needed  for  the  subcases  associated  with  the  suB’th  subscript,  control  is 
returned  to  the  MAPOL  sequence. 

If  SPCF  requests  exist,  the  preliminary  computations  are  performed  in  the  arsfcf  module.  It  computes: 
[QGVl]  =  [KFS]T(DF)  +  [KSS]  (YS) 

for  all  the  appropriate  columns  of  UAF  that  are  associated  with  the  SDB’th  subscript.  The  input  YS  vector 
is  expanded  to  contain  the  correct  number  of  columns. 

Then  the  computation  of  the  applied  loads  is  done.  First,  the  BGPDT  data  are  read  and  the  OORIDLGD 
relation  is  opened  for  output.  Then  the  loads  for  each  subcase  in  the  subscript  is  solved  for  subject  to 
the  existence  of  a  print  request  for  that  subcase  (either  LOAD  or  spcf).  The  following  loads  are  computed: 


Matrix  of  accelerations  for  all  SAERO  subcases  in  the  current  boundary 
condition  in  the  order  the  subcases  appear  in  the  case  relation.  (Input) 

The  off-diagonal  matrix  partition  of  the  independent  degrees  of  freedom 
that  results  from  the  spc  partitioning.  (Input) 

The  dependent  DOF  diagonal  matrix  partition  of  the  independent  degrees 
of  freedom  that  results  from  the  spc  partitioning.  (Input) 

Matrix  of  free  (f-set)  static  displacements  for  ail  saero  subcases  in  the 
current  boundary  condition  in  the  order  the  subcases  appear'  in  the  case 
relation.  (Input) 

Vector  of  enforced  displacements  for  the  boundary  condition  (one  column). 
(Input) 

]  Partitioning  vector  to  divide  the  independent  DOFs  into  the  free  and  SPC 

DOFs.  (Input) 

]  Partitioning  vector  to  divide  the  g-set  DOFs  into  the  MPC  and  inde¬ 

pendent  DOFs.  (Input) 

Partitioning  vector  to  divide  the  f-set  DOFs  that  may  include  <SJR  gener¬ 
ated  scalar  points  into  the  original  f-set  DOFs. 

Denotes  dynamic  reduction  in  the  boundary  condition. 

=  ONoGDR 
=  -1  GDR  is  used 
(Input,  Integer) 

The  unstructured  entity  of  DOF  masks  for  all  the  points  in  the  current 
boundary  conditions.  (Input) 

Relation  of  loads  on  structural  grid  points.  (Output) 
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Rigid  Air  Loads  on  the  Structural  Grids 
■=  QDP*  [GTKG]  [AIRFRC]  [DELTA] 

Flexible  Correction  to  the  Rigid  Air  Loads 

■  QDP*  [GTKG]  [AIC]T[G3TKG]T[UAG] 

Tbtal  Applied  Load 

«  Rigid  +  Flexible 

Inertial  Load 

*  -  [MGG]  [AAG] 

Where  the  appropriate  inputs  are  not  available,  the  computations  are  simply  ignored  with  no  warning. 
Thus,  the  optional  calling  arguments  may  be  used  to  perform  parts  of  the  computations  without 
requiring  that  all  pieces  be  provided. 

Then,  the  output  loads  matrices  are  opened  and  the  CASE  loads  print  and  punch  requests  are  used  to 
load  the  OGRIDLOD  relation  with  the  RIGID,  FLEXIBLE,  APPLIED  and  INERTIA  loads. 

Finally,  if  any  SPCF  output  requests  exist  the  APPLIED  loads  that  were  computed  are  combined  with 
the  QGVl  terms  to  result  in  the  spc  reaction  forces: 

[SPCF]  ”  [QGVl]  -  [Applied  load] 

For  each  DOF  for  which  spc  forces  have  been  requested. 

Design  Requirements: 

1.  SPC  force  computations  for  other  disciplines  occur  in  the  ofpspcf  module. 

2.  Only  those  arguments  that  are  present  will  be  used.  If  data  are  missing,  the  dependent  terms  will  be 
omitted  from  the  output. 

Error  Conditions: 

None 
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Engineering  Application  Module:  OFPDISP 
Entry  Point:  OFPDSP 


Purpose: 

Tb  print  selected  displacements,  velocities  and/or  accelerations  from  any  analyses  in  the  current 
boundary  condition. 

MAPOL  Calling  Sequence: 

CALL  OFPDISP  (  NOMOPTBC ,  BC,  NITER,  GSIZE,  BGPDT(BC),  ESIZE(BC),  PSIZE(BC), 
OGRIDDSP,  [UG (BC) ] ,  [AG (BC) ] ,  [UAG (BC) ] ,  [AAG (BC) ] ,  [BLDG] , 
[BLOE]  ,  [DTRANG]  ,  [DTRANE]  ,  [DFREQG]  ,  [CTFREQE]  ,  LAMBDA, 

[PHIG(BC) ] ,  [PHIBG(BC) ] ,  LSTFLG  ) ; 


NOMOPTBC 

BC 

NITER 
GSIZE 
BGPDT (BC) 
ESIZE (BC) 

PSIZE (BC) 

OGRIDDSP 
[UG(BC) ] 
[AG(BC) ] 
[DAG (BC) ] 
[AAG  (BC)  ] 
[BLOG] 

[BLOE] 

[UTRANG] 

[OTRANE] 

[UFREQG] 

[OFREQE] 

LAMBDA 


Number  of  optimization  boundary  conditions  (Integer,  Input) 

Boundary  condition  identification  number  -'Integer,  Input) 

Iteration  number  for  the  current  design  iteration  (Integer,  Input) 

The  size  of  the  structural  set  (Integer,  Input) 

Relation  of  basic  grid  point  coordinate  data  (Input) 

The  number  of  extra  point  degrees  of  freedom  in  the  boundary  condition 
(Integer,  Input) 

The  size  cf  the  physical  set  for  the  current  boundary  condition. 

(Integer,  Ir  put) 

Relation  for  storage  of  displacement  data  (Input) 

Matrix  of  global  displacements  from  statics  analyses  (Input) 

Matrix  of  global  accelerations  from  statics  analyses  (Input) 

Matrix  of  global  displacements  from  saero  analyses  (Input) 

Matrix  of  global  accelerations  from  SAERO  analyses  (Input) 

Matrix  of  global  displacements/velocities/accelerations  for  BLAST  re¬ 
sponse  analyses  (Input) 

Matrix  of  extra  point  displacements/velocities/  accelerations  for  blast  re¬ 
sponse  analyses  (Input) 

Matrix  of  global  displacements/velocities/  accelerations  for  TRANSIENT  re¬ 
sponse  analyses  (Input) 

Matrix  of  extra  point  displacements/velocities/  accelerations  for  TRAN¬ 
SIENT  response  analyses  (Input) 

Matrix  of  global  displacements/velocities/  accelerations  for  frequency  re¬ 
sponse  analyses  (Input) 

Matrix  of  extra  point  displacements/velocities/  acceleration?  for  fre¬ 
quency  response  analyses  (Input) 

Relational  entity  containing  the  output  from  the  real  eigenanalysL? 

(Input) 
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[PHIS  <BC)  ]  Matrix  of  global  eigenvectors  from  real  eigenanalysis  for  MODES  analyses 

(Input) 

[PHIGB  <BC)  ]  Matrix  of  global  eigenvectors  for  BUCKLING  analyses  (Input) 

LSTFLG  Integer  flag  to  indicate  if  for  last  iteration  output  only  (Integer,  Input) 

=  1  for  last  iteration  only 
=  0  other  general  cases 

Application  Calling  Sequence: 

None 

Method: 

The  module  begins  by  reading  the  CASE  relation  nodal  response  quantity  print  options  for  the  current 
boundary  condition.  The  following  print  requests  are  treated  in  the  OFPDISP  module: 

(1)  DISPLACEMENT 

(2)  VELOCITY 

(3)  ACCELERATION 

(4)  ROOTS  (for  normal  modes  analyses) 

As  the  CASE  data  are  searched,  the  FLTFLG  and  MODFLG  logicals  are  set  to  true  if  either  FLUTTER  or 
MODES  disciplines  are  associated  with  these  print  requests.  If  no  prints  are  requested,  the  module 
terminates,  otherwise,  the  iterlist,  GRIDLIST,  modelist,  timelist  and  EREQLI3T  data  are 
prepared  for  easy  retrieval  in  determining  which  nodes  and  subcases  are  requested  in  each  case. 

The  BGPDT  data  are  then  read  into  open  core  and  the  number  of  extra  point  degrees  of  freedom  in  the 
current  boundary  condition  is  determined.  Finally,  the  code  checks  to  see  if  any  flutter  displacements 
(eigenvectors)  have  been  requested  for  an  optimization  boundary  condition.  If  so,  the  request  is  explicitly 
turned  off  since  ASTROS  does  not  compute  the  eigenvector  for  optimization  boundary  conditions.  The 
next  segment  of  code  is  set  aside  for  special  discipline  dependent  processing.  In  this  module,  the  flutter 
eigenvector  print  requires  the  transformation  of  the  modal  participation  factors  for  any  flutter  eigen¬ 
vectors  into  physical  coordinates  using  the  input  phig  matrix  and  the  FLUTREL  and  FLUTMODE  entities 
that  were  created  in  the  fluttran  module.  Again,  if  no  flutter  conditions  were  found  in  the  analysis, 
the  module  explicitly  turns  off  the  print  request.  Otherwise,  the  physical  mode  shape  is  computed  and 
stored  in  a  pair  of  scratch  entities:  one  for  the  structural  degrees  of  freedom  and  one  for  the  extra  point 
degrees  of  freedom. 

The  main  loop  in  the  module  now  begins.  This  loop  is  over  all  the  disciplines  that  have  nodal  response 
quantities.  For  each  discipline,  there  is  a  loop  over  all  the  CASE  tuples  retrieved  at  the  beginning  of  the 
module.  Only  those  CASE  tuples  matching  the  current  discipline  are  treated  at  each  pass  of  the  outermost 
loop.  The  D3P3UB  submodule  is  called  for  each  CASE  tuple  to  determine  the  number  and  identification 
numbers  for  each  subcase  for  which  output  is  desired.  A  subcase  is  considered  to  be  one  displacement/ve¬ 
locity/acceleration  vector  for  a  particular  time  step,  frequency  step,  load  condition,  etc.  Then,  depending 
on  the  nature  of  the  discipline,  one  of  five  print  routines  is  called  to  read  into  memory  the  proper  nodal 
vector  and  print  the  terms  to  the  user  output  file.  Once  all  the  subcases  for  the  current  CASE  tuple  have 
been  processed,  the  case  tuple  loop  continues  for  the  current  discipline.  When  all  disciplines  or  all  CASE 
tuples  have  been  processed,  the  module  terminates. 
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Design  Requirements: 


1.  The  OFPDISP  module  is  designed  to  be  called  at  the  conclusion  of  the  boundary  condition  loop  ’.vhen 
all  the  physical  nodal  response  quantities  have  been  computed  for  all  the  analyzed  disciplines. 

Error  Conditions: 

None 
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Engineering  Application  Module .  OFPDLQAD 

Entry  Point:  OFPDLD 

Purpose: 

Processes  the  solution  control  load  output  requests  for  the  current  boundary  condition  for  dynamic  loads 
(transient,  frequency  and  gust)  and  stores  the  loads  on  the  physical  degrees  of  freedom  to  the  OGRIDLOD 
relation  for  those  subcases  and  grids  selected  in  solution  control. 


MAPOL  Calling  Sequence: 

CALL  OFPDLQAD 

{  NITER,  BC,  BGPDT (BC) ,  PSIZE(BC),  E3IZE(BC),  [PHXG(BC)3, 
[PTGLOAD] ,  [PTHLOAD] ,  [PFGLOAD] ,  [PFHLOAD] ,  OGRIDLOD  ) ; 

NITER 

Current  design  iteration  number.,  (Integer,  Input) 

BC 

Current  boundary  condition  number.  (Integer,  Input) 

BGPDT (BC) 

Relation  of  basic  grid  point  data  for  the  boundary  condition  (including 
any  extra  points  and  gdr  scalar  points  which  may  be  added  by  the  GDR 
module).  (Input) 

PSIZE(SC) 

The  size  of  the  physical  set  for  the  current  boundary  condition. 

(Integer,  Input) 

E3IZE (BC) 

Number  of  extra  point  DOFs  defined  for  the  boundary  condition. 

(Integer,  Output) 

[PHIGtBC) ] 

Matrix  of  normal  mode  eigenvectors  in  the  structural  g-Bet  (Input) 

[PTGLOAD] 

Matrix  of  g-set  applied  dynamic  loads  for  the  direct  transient  analyses  in 
the  current  boundary  condition.  (Input) 

[PTH LOAD 3 

Matrix  of  h-set  applied  dynamic  loads  for  the  modal  transient  GUST  analy¬ 
ses  in  the  current  boundary  condition.  (Input) 

[PFGLOAD3 

Matrix  of  g-set  applied  dynamic  loads  for  the  direct  frequency  analyses  in 
the  current  boundary  condition.  (Input) 

[PFHLOAD3 

Matrix  of  h-sst  applied  dynamic  loads  for  the  modal  frequency  analyses 
with  gust  in  the  current  boundary  condition.  (Input) 

OGRIDLOD 

Relation  of  applied  loads  on  structural  grid  points.  (Output) 

Application  Calling  Sequence: 

None 

Method: 

The  case  relation  is  read  for  all  transient  and  frequency  response  analysis  and  the  LOADPRNT  print  and 
punch  requests  for  loads  are  examined.  If  any  requests  exist,  processing  continues  by  opening  the  bgpdt 
and  reading  the  intemal/external  point  identifications  to  allow  storing  the  matrix  data  or  the  osridlod 
relation  labelled  with  the  external  ids. 
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If  any  GUST  loads  are  requested  the  ir^dal  dynamic  loads  are  transformed  to  the  physical  degrees  of 
freedom  as: 

[PGUSTT]  »  [PHIG]  [PTHLGMij  for  transient  gust 
[PGUSTP]  *  [PHIG]  [PFHLQAD j  for  karri  '•me  fust 

Tb  perform  these  operations,  the  normal  modes  muot  be  e-  landed  to  include  extra  points  for  the  single 
subcase  of  transient  and  or  frequency  that  is  allowed.  '’hen  the  multiplications  are  performed. 

Finally,  once  all  the  direct  matrices  are  available,  the  C32E  control  print  requests  are  processed,  the 
corresponding  columns  are  identified  by  interpreting  she  XXJfflS  or  EREQ  options  and  the  GRIDLIST  data 
are  read  to  determine  which  points  are  chosen.  The  terms  are  then  written  to  the  OGRTDLOD  relation  as 
applied  loads. 


Error  Conditions: 
None 
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Engineering  Application  Module:  OFPF.DR 


Entry  Point:  OFPEDR 


Purpose: 

lb  print  selected  element  stress,  strain,  force  and/or  strain  energies  from  any  analyses  in  the  current 
boundary  condition. 

MAPOL  Calling  Sequence: 

CALL  OFPEDR  (  BC,  HSISE(BC),  NITER,  L3TFL3  ); 


BC 

HSIZE (BC) 

NITER 


Boundary  condition  identification  number  (Integer,  Input) 

Number  of  modal  dynamic  degrees  of  freedom  in  the  current  boundary 
condition  (Input) 

Iteration  number  for  the  current  design  iteration  (Integer,  Input) 


lstflg  Integer  flag  to  indicate  if  for  last  iteration  output  only  (Integer,  Input) 

=  1  for  last  iteration  only 
=  0  other  general  cases 


Application  Calling  Sequence: 
None 


Method: 

The  module  begins  by  reading  the  CASE  relation  element  response  quantity  print  options  for  the  current 
boundary  condition.  The  following  print  requests  are  treated  in  the  ofpedr  module: 

(1)  STRESS 

(2)  STRAIN 

(3)  FORCE 

(4)  ENERGX 

If  no  prints  are  requested,  the  module  terminates,  otherwise,  the  ITERLIST,  E1EMLIST,  MODELI3T, 
TIMELIST  and  FREQLIST  data  are  prepared  for  easy  retrieval  in  determining  which  elements  and 
subcases  are  requested  in  each  case.  The  main  loop  in  the  module  now  begins.  This  loop  is  over  all  the 
disciplines  that  have  element  response  quantities. 

For  each  disriplii  ,  there  is  a  loop  over  all  the  case  tuples  retrieved  at  the  beginning  of  the  module. 
Only  those  CASE  tuples  matching  the  current  discipline  are  treated  at  each  pass  of  the  outermost  loop. 
The  OFPSOB  submodule  is  called  for  each  case  tuple  to  determine  the  number  and  identification 
numbers  for  each  subcase  for  which  output  is  desired.  A  subcase  is  considered  to  be  one  displacement 
vector  for  a  particular  time  step,  frequency  step,  load  condition,  etc.  For  each  subcase,  the  set  of  element 
response  print  utilities  (one  for  each  element  type)  are  called  for  each  of  the  four  quantities  that  can  be 
printed.  3f  the  strain  energy  is  requested,  the  ofpese  submodule  is  called  to  compute  the  total  strain 
energy  for  the  current  displacement  field  as  a  preface  operation  prior  to  the  element  dependent  print 
routines.  Once  all  the  quantities  for  all  the  subcases  for  the  current  case  tuple  have  been  processed, 
the  CASS  tuple  loGp  continues  for  the  current  discipline.  When  all  disciplines  or  all  case  tuples  have 
been  processed,  the  module  terminates. 
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Design  Requirements: 


1.  The  OSTPEDR  module  is  designed  to  he  called  at  the  conclusion  of  the  boundary  condition  loop  when 
all  the  physical  nodal  response  quantities  have  been  computed  for  all  the  analyzed  disciplines. 

2.  The  EDR  module  must  have  been  called  to  store  the  computed  element  response  quantities  onto  the 
EOaacc*  entities  which  are  read  by  the  ofpedr  module. 

Error  Conditions: 

None 
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Engineering  Application  Module:  OFPGRAD 
Entry  Point:  OFPGRA 


Stores  the  data  necessary  to  satisfy  the  solution  control  print  and  punch  requests  o gradient  and 
c gradient  (objective  function  gradient  and  constraint  gradient,  respectively). 

tPOL  Calling  Sequence: 

CALL  OFPGRAD  (  NITER,  NOMOPTBC ,  [AMAT],  GLBDES,  CONST,  GRADIENT  ); 


NITER 

NOMOPTBC 

[AMAT] 


GLBDES 


CONST 


GRADIENT 


Design  iteration  number.  (Integer,  Input) 

Number  of  optimization  boundary  conditions.  (Integer,  Input) 

The  matrix  of  constraint  gradients  for  active  constraints  in  the  current  de¬ 
sign  iteration.  (Input) 

The  relation  of  giobal  design  variable  values  and  objective  function  sensi¬ 
tivities  for  all  design  iterations  that  have  been  analyzed.  (Input) 

The  relation  cf  applied  design  constraints  for  all  design  iterations.  (Input) 

The  relation  of  output  constraint  gradients  for  the  requested  constraints 
and  design  variables  that  satisfy  the  Solution  Control  CGRADIENT  and 
ogradient  output  requests.  (Output) 


application  I 


Method: 


The  optimize  relation  is  read  to  determine  if  and  OGRADIENT  or  CGRADIENT  print  or  punch  requests 
exist.  If  they  do,  processing  continues  by  determining  if  this  iteration  is  in  the  set  of  iterations  selected. 
If  it  is,  the  the  AMAT  matrix  is  opened  and  read  into  memory  as  are  the  glbdes  entries  for  the  current 
iteration.  The  CONST  relation  is  read  into  memory  and  reordered  to  match  the  AMAT  matrix.  Then  the 
GRADIENT  entity  is  loaded  with  the  objective  or  constraint  gradient  terms  for  the  requested  constraints 
and  global  design  variables. 

sign  Requirements: 


Error  Conditions: 
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Engineering  Application  Module:  OFPLOAD 

Entry  Point:  OFPLOD 

Purpose: 

lb  print  selected  applied  external  loads  from  any  analyses  in  the  current  boundary  condition. 
MAPOL  Calling  Sequence: 

CALL  OFPLOAD  (  NTJMOFTBC,  BC,  NITER,  GSIZE,  BQPDT(BC)  ,  PSIZE<BC)  ,  [PG]  , 
TBMTYP,  QDP,  [GTKG],  [AIRFRC (MIND EX) ] ,  [DELTA]  ); 


NOMOPTBC 

Number  of  optimization  boundary  conditions  (Integer,  Input) 

BC 

Boundary  condition  identification  number  (Integer,  Input) 

NITER 

Iteration  number  for  the  current  design  iteration  (Integer,  Input) 

GSIZE 

The  size  of  the  structural  set  (Integer,  Input) 

BGPDT (BC) 

Relation  of  basic  grid  point  coordinate  data  (Input) 

PSIZE (BC) 

The  size  of  the  physical  set  for  the  current  boundary  condition. 

(Integer,  Input) 

[PG] 

Matrix  of  applied  loads  for  statics  analyses  in  the  current  boundary 
condition  (Input) 

THMTYP 

The  trim  type  for  the  steady  aeroelastic  analyses  «*  0  zero  degree  of  free¬ 
dom  trim  «  1  lift  only  trim  «  2  lift/pitching  moment  trim  (Integer,  Input) 

QDP 

Dynamic  pressure  for  the  SAERO  analyses  in  the  current  boundary  condi¬ 
tion  (Real,  Input) 

[GTKG] 

Matrix  containing  the  steady  aerodynamic  spline  in  the  structural  set 
(Input) 

[AIRFRC  (MINDEX)  ] 

Matrix  containing  the  aerodynamic  forces  for  unit  configuration  parame¬ 
ters  for  the  current  Mach  number  and  Symmetry  (Input) 

[DELTA] 

Matrix  containing  the  configuration  parameter  values  resulting  from  the 
current  trim  condition  (Input) 

Application  Calling  Sequence: 

None 

Method: 

The  module  begins  by  reading  the  CASE  relation  applied  load  print  options  for  the  current  boundary 
condition.  The  LOAD  print  requests  are  treated  in  the  OFPLOAD  module  for  all  ASTROS  disciplines.  As 
the  case  data  are  searched,  the  aroflg  logical  is  set  to  TRUE  if  any  SAERO  cases  with  a  THMTXP  greater 
than  zero  are  found.  If  no  prints  are  requested,  the  module  terminates,  otherwise,  the  GRIDLIST, 
MODELIST,  timelist  and  FREQLIST  data  are  prepared  for  easy  retrieval  in  determining  which  nodes 
and  subcases  are  requested  in  each  case.  The  BGPDT  data  are  then  read  into  open  core  and  the  number 
of  extra  point  degrees  of  freedom  in  the  current  boundary  condition  is  determined.  The  next  segment  of 

code  is  set  aside  for  special  discipline  dependent  processing.  In  this  module,  the  steady  air  loads 
associated  with  trim  analyses  must  be  computed  from  the  AIRFRC  matrix  of  loads  due  to  "unit" 
configuration  parameters  and  the  DELTA  matrix  of  trimmed  configuration  parameters.  The  result  must 
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then  be  splined  to  the  structural  degrees  of  freedom  using  the  GTKG  spline  transformation  matrix.  The 
structural  applied  loads  are  stored  in  a  scratch  entity  for  use  in  the  subsequent  print  processing.  The 
main  loop  in  the  module  now  begins.  This  loop  is  over  all  the  disciplines  that  have  applied  loads.  For 
each  discipline,  there  is  a  loop  over  all  the  case  tuples  retrieved  at  the  beginning  of  the  module.  Only 
those  case  tuples  matching  the  current  discipline  are  treated  at  each  pass  of  the  outermost  loop.  The 
£>ODSUB  submodule  is  called  for  each  CASE  tuple  to  determine  the  number  and  identification  numbers 
for  each  subcase  for  which  output  is  desired.  A  subcase  is  considered  to  be  one  load  vector  for  a  particular 
time  step,  frequency  step,  load  condition,  etc.  Then,  depending  on  the  nature  of  the  discipline,  one  of 
two  print  routines  is  called  to  read  into  memory  the  proper  vector  and  to  print  the  terms  to  the  user 
output  file.  Once  all  the  subcases  for  the  current  case  tuple  have  been  processed,  the  CASE  tuple  loop 
continues  for  the  current  discipline.  When  all  disciplines  or  all  CASE  tuples  have  been  processed,  the 
module  terminates. 

Design  Requirements: 

1.  The  OFPLOAD  module  is  designed  to  be  called  at  the  conclusion  of  the  boundary  condition  loop. 

Error  Conditions: 

None 
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Engineering  Application  Module:  OFPMROOT 
Entry  Point:  OFPMRT 


Purpose: 

Processes  the  solution  control  normal  modes  root  output  requests. 


MAPOL  Calling  Sequence: 


CALI.  OFPMROOT 
NITER 
BC 

NUMDPT3C 

LAMBDA 

LASTFLAG 


NITER,  BC,  NOMOPTBC ,  LAMBDA,  LASTFLAG  ) ; 

Current  design  iteration  number.  (Integer,  Input) 

Current  boundary  condition  number.  (Integer,  Input) 

The  number  of  optimization  boundary  conditions.  (Integer,  Input) 

The  relation  of  normal  modes  eigenvalues  for  all  boundary  conditions  and 
design  iterations.  (Input) 

An  optional  argument  which,  if  nonzero,  implies  that  the  call  is  being 
made  only  to  satisfy  I  TER* LAST  print  or  punch  requests.  (Integer,  Input) 


Application  Calling  Sequence: 
None 


Method: 

The  case  relation  is  read  to  obtain  the  print/punch  requests  for  roots.  If  any  requests  exist,  they  are 
processed.  If  the  lastflag  is  nonzero,  only  those  requests  in  which  the  iter=last  flag  is  set  in  the 
rootprnt  case  relation  attribute  are  considered. 

For  the  modes  selected  by  the  MODELIST,  the  OEIGS  and  LAMBDA  entities  are  read  and  the  eigenvalue 
extraction  summary  table  and  the  extracted  eigenvalues  are  printed  to  the  output  file.  Punch  requests 
are  ignored  since  the  data  are  stored  already  on  the  lambda  relation. 

Design  Requirements: 

None 


Error  Conditions: 
None 
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Engineering  Application  Module:  ofpspcf 

Entry  Point:  OFPSPF 
Purpose: 

Recovers  single-point  forces  of  constraint  and  loads  the  results  to  the  ogridlod  relation 
MAPOL  Calling  Sequence: 


CALL  OFPSPCF  < 

NITER,  BC,  DISC,  CMPLX,  GSIZE,  ESIZE(BC),  NGDR,  [KFS] ,  [KSS], 
[OF]  ,  [YS  (BC)  ]  ,  [PS]  ,  [PNSF(BC)  ]  ,  [PGMN(BC)  ]  ,  [PFJX]  , 

[PHIG(BC)],  [PGLOAD] ,  [PHLOAD] ,  BGPDT (BC) ,  OGRIDLOD  ); 

NITER 

Current  design  iteration  number.  (Optional,  Integer,  Input) 

BC 

Current  boundary  condition  number.  (Integer,  Input) 

DISC 

Integer  key  indicating  the  discipline  whose  SPC  forces  are  to  be  recovered. 

=1  for  statics 

=2  for  modes 

=4  for  flutter 

»5  for  transient  analysis 

*6  for  frequency  analysis 

=»8  for  nuclear  blast 

Note  that  static  aeroelasticity  (DISC=3)  is  supported  in  the  OFPALQAD 
module.  (Integer,  Input) 

CMP  LX 

Integer  flag  indicating  whether  the  discipline’s  displacement  field  is  real 
(=1)  or  complex  (=2).  (Integer,  Input) 

GSIZE 

Number  of  degrees  of  freedom  in  the  g-set  including  those  that  may  have 
been  added  by  GDR  (Integer,  Input) 

ESIZE (BC) 

Number  of  extra  point  DOFs  defined  for  the  boundary  condition.  (Integer, 
Output) 

N3DR 

Denotes  dynamic  reduction  in  the  boundary  condition. 

=  0  No  GDR 
=  -1  GDR  is  used 
(Input,  Integer) 

[KFS] 

The  off-diagonal  matrix  partition  of  the  independent  degrees  of  freedom 
that  results  from  the  SPC  partitioning.  (Input) 

[KSS] 

The  dependent  DOF  diagonal  matrix  partition  of  the  independent  degrees 
of  freedom  that  results  from  the  SPC  partitioning.  (Input) 

[UF] 

Matrix  of  free  (f-set)  static  displacements  for  all  the  disc  subcases  in  the 
current  boundary  condition  in  the  order  the  subcases  appear  in  the  CASE 
relation.  (Input) 

[XS (BC) ] 

Vector  of  enforced  displacements  for  the  boundary  condition  (one  column). 
(Optional,  Input) 

[PS] 

Matrix  of  static  loads  applied  to  the  SPC  DOF’s  (Partition  of  the  free  DOF 
loads  matrix)  (Optional,  Input) 

[PNSF(BCJ  ] 

Partitioning  vector  to  divide  the  independent  DOFs  into  the  free  and  SPC 
DOFs.  (Input) 
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[PGMN  (BC)  ] 

Partitioning  vector  to  divide  the  g-set  DOFs  into  the  mpc  and  inde¬ 
pendent  DOFs.  (Input) 

[PFJK] 

Partitioning  vector  to  divide  the  f-set  DOFs  that  may  include  GDR  gener¬ 
ated  scalar  points  into  the  original  f-set  DOFs.  (Optional,  but  required  if 
NGDR  <>0;  Input) 

[PHIG(BC) ] 

Matrix  of  normal  mode  eigenvectors  in  the  structural  g-set 
(Optional,  Input) 

[PGLOAD] 

Matrix  of  g-set  applied  dynamic  loads  for  the  direct  transient  or  fre¬ 
quency  analyses  (as  appropriate  for  Disc)  in  the  current  boundary  condi¬ 
tion.  (Optional,  Input) 

[PHLOAD] 

Matrix  of  h-set  applied  dynamic  loads  for  the  modal  transient  or  fre¬ 
quency  GUST  analyses  (as  appropriate  for  Disc)  in  the  current  boundary 
condition.  (Optional,  Input) 

BGPDT(BC) 

Relation  of  basic  grid  point  data  for  the  boundary  condition  (including 
any  extra  points  and  GDR  scalar  points  which  may  be  added  by  the  GDR 
module).  (Input) 

OGRIDLOD 

Relation  of  loads  on  structural  grid  points.  (Output) 

Application  Calling  Sequence: 

None 

Method: 

This  module  computes  the  spc  reaction  forces  for  all  disciplines  in  ASTROS  except  saero  andNPSAERO. 
NPSAERO  has  no  structural  loads  and  the  SAERO  SPC  forces  are  computed  in  the  ofpaload  module  where 
the  applied  loads  (an  input  to  the  SPC  computations)  are  computed. 

First  the  case  relation  is  read  for  all  entries  with  aDISFLAG  of  Disc  for  the  current  boundary  condition. 
Then  the  SPCF  print  requests  are  examined  to  determine  if  any  output  is  needed  for  this  discipline, 
design  iteration,  etc.  If  not,  the  module  terminates  otherwise  computations  continue  with  the  creation 
of  scratch  entities  to  hold  the  constituent  parts  of  the  SPC  calculations.  The  BGPDT  data  are  read  into 
memory  and  the  ogridlod  relation  is  opened  in  preparation  for  output. 

The  existence  of  enforced  displacements,  YS  and  loads  on  the  SPC  dofs,  ps  is  checked  and  logical  flags 
are  set  for  downstream  computations.  If  gdr  was  used  (as  indicated  by  NGDR  <>0),  the  PFJK  partition 
matrix  is  used  to  extract  the  original  f-set  DOF  from  UF  from  the  input  set  which  includes  gdr  scalar 
points. 

Then  some  discipline  dependent  processing  takes  place.  If  disc  =  4  (flutter),  the  FLMODE  hidden 
entity  is  read  and  the  flutter  eigenvectors  (if  any)  are  read,  stripped  of  the  extra  point  degrees  of  freedom 
and  reduced  to  the  f-set.  Transient  and  frequency  disciplines  require  special  processing  because  of  the 
nature  of  the  displacement  matrices  (containing  velocities  and  accelerations).  This  processing  is  done 
in  dyspcf  and  results  in  a  g-set  sized  matrix  of  the  loads  applied  to  the  spc  DOFs  for  each  time  or 
frequency  step.  GUST  loads  are  treated  here  to  recover  the  direct  applied  loads  from  the  phloab  input. 
Extra  points  are  partitioned  out  of  these  loads  matrices  if  needed. 

Then  the  actual  recovey  process  begins.  First  the  QSV  matrix  of  spc  forces  are  computed  from  ths 
appropriate  constituent  terms 

IflSV]  =  [KFS]T{UF)  +  [ESS] {YS}  -  {PS} 
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where  YS  has  been  expanded  to  have  the  appropriate  number  of  columns  and  the  proper  terms  are 
ignored  if  YS  or  PS  is  blank  or  empty. 

Then  the  QSV  matrix  is  expanded  to  the  g-set,  the  nonzero  terms  are  read  and  compared  to  the  output 
requests  and  the  appropriate  terms  are  loaded  to  the  OGRIDLOD  relation.  For  the  dynamic  response 
disciplines,  the  applied  loads  PS  are  extracted  from  the  g-set  output  of  the  dyspcf  submodule  and  the 
reaction  forces  are  adjusted  accordingly. 

Design  Requirements: 

1.  saero  single  point  constraint  reactions  are  computed  in  the  ofpaload  module  where  the  applied 
loads  are  computed. 

Error  Conditions: 

None 
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Engineering  Application  Module:  pfbulk 

Entry  Point:  PFBULK 

Purpose: 


lb  perform  a  number  of  preface  operations  to  form  additional  collections  of  data  and  to  make  error  checks 
not  done  in  IFP  to  identify  input  errors  before  costly  analyses  are  performed. 

MAPOL  Calling  Sequence: 

CALL  PFBULK  (  GSIZEB, 

G3IZEB 

EOSUMMRY 

EODISC 

GPFELEM 

Application  Calling  Sequence: 

None 
Method: 

The  module  performs  tests  on  selected  bulk  data  entities  to  see  if  they  contain  data.  If  they  do,  the 
indicated  subroutine  is  called  to  generate  further  data  and  perform  error  checks: 


BULK  DATA 

SUBROUTINE 

GENERATED  ENTITY 

TEMP,  TEMPD 

PKETMP 

GRIDTEMP 

FREQ,  FEEQl,  FREQ2 

PREFRQ 

FREQL 

TSTEP 

PRETST 

OTL 

EOSUMMRY,  EODISC,  QPFELEM  ); 

Length  of  the  g-set  vectors  (Integer,  Input) 

Relational  entity  containing  the  summary  of  entities  for  which  element  re¬ 
sponse  quantities  are  desired  (Output) 

Unstructured  entity  referred  to  by  an  attribute  of  eosuhmry  containing 
the  set  of  disciplines  and  subcases  for  the  element  response  quantities 

Relational  entity  containing  the  set  of  elements  connected  to  grid  points 
for  which  grid  point  forces  are  desired  (Output) 


The  module  also  checks  that  constraint  requests  tpecified  in  the  flutter  solution  control  command 
have  corresponding  DCONFLT  bulk  data  entries. 

As  a  final  step,  the  PFBULK  module  performs  the  preliminary  processing  of  solution  control  print  requests 
that  depend  on  elements.  These  include  all  the  element  response  quantities  (i.e.,  stress  or  strain)  and 
the  grid  point  force  balance.  The  first  stage  is  performed  in  the  pregpf  submodule  which  builds  the 
GPFELEM  relation  from  the  element  connectivity  data  and  the  sets  of  nodes  for  which  a  force  balance  in 
requested.  Then  the  PREEDR  submodule  is  called  to  build  the  EOSUMMRY  and  EODISC  entities  which  list 
those  elements  for  which  element  data  recovery  should  be  performed  in  the  edr  module.  These  entities 
are  also  used  in  ofpedr  to  direct  the  printing  of  the  computed  quantities. 
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1.  This  is  a  preface  module  that  called  after  EMG  and  MAKE3T 


Error  Conditions: 
None 


i 
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Engineering  Application  Module:  QHHLGEN 


Entry  Point:  QHHGEN 
Purpose: 

Tb  compute  the  discipline  dependent  unsteady  aerodynamic  matrices  for  gust  analyses  in  the  modal 
dynamic  degrees  of  freedom. 

MAPOL  Calling  Sequence: 

CALL  QHHLGEN  (  BC,  ESIZE(BC),  [QKKL] ,  [QKJL] ,  [UGTXA] ,  [PHIA],  [PHIKH], 

[QHHL] ,  fQHJL]  ) ; 


ESI7.S  (BC) 


[QKKL] 


[Q5JL3 


[UGTHA] 


[PHIA] 

[PHIKH] 


[QHHL] 


[QHJL] 


Boundary  condition  identification  number  (Integer,  Input) 

The  number  of  extra  point  degrees  of  freedom  in  the  boundary  condition 
(Integer,  Input) 

Matrix  list  containing  the  matrix  product: 

[SKJ]  [AJJT]"T(  [D1JK]  +  ik[D2JK]) 
used  for  flutter  and  gust  analyses  (Input) 

Matrix  list  containing  the  matrix  product: 

[SKJ]  [AJJT]‘T 
used  for  gust  analyses  (Input) 

Matrix  containing  the  unsteady  aerodynamic  spline  in  the  analysis  set 
(Input) 

Matrix  containing  the  real  eigenvectors  in  the  analysis  set  (Input) 

Matrix  containing  the  matrix  product: 

[UGTXA] [PHIA] 

with  the  analysis  set  expanded  to  include  extra  points  (Output) 

The  modal  unsteady  aerodynamic  influence  coefficients  for  gust  (Output): 
[PHIKH]  T[QKK]  [PHIKH] 

The  modal  unsteady  aerodynamic  influence  coefficients  for  gust: 
[PHIEH]T[QKJ]  (Output) 


hcation  < 


Method: 

The  QHLLPEN  module  begins  by  retrieving  all  the  case  tuples  for  the  current  boundary  condition.  The 
number  of  gust  options  on  transient  or  frequency  response  disciplines  are  counted  to  determine  what 
actions  are  required  by  the  module.  If  gust  conditions  do  not  exist,  control  returns  to  the  executive.  If 
Q2BB  and  QJB  are  required,  the  module  continues  by  reading  the  BGFDT  data  to  determine  the  size  of 
the  direct  dynamic  degrees  of  freedom  including  extra  points.  If  extra  points  exist,  the  normal  modes 
and  the  unsteady  spline  matrix  (input  in  the  analysis  set)  are  expanded  to  include  the  extra  point  degrees 
of  freedom.  The  module  then  computes  the  PHIKH  matrix  of  structural  mode  shapes  splined  to  the 
aerodynamic  degrees  of  freedom.  QHLLGEN  then  calls  the  PRONMK  utility  to  prepare  the  ukmk  data  for 
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the  discipline  dependent  unsteady  aerodynamic  matrices.  The  total  number  of  m-k/symmetry  sets 
associated  with  the  QKK  matrix  are  computed  and  the  requisite  memory  for  the  subsequent  computations 
is  obtained.  The  module  then  proceeds  with  the  premultiplication  of  the  QRK  matrix  list  by  the  phikh 
matrix: 


[QHKL]  =  [PHIKH] [QKRL] 

The  QHLL  output  matrix  is  then  flushed  and  computed  using  one  of  two  paths.  If  there  is  only  one 
m-k/symmetry  set  (which  is  very  rare),  the  QHLL  matrix  may  be  formed  by  a  post-multiplication  of  QHKL 
in  one  step.  If  more  than  one  matrix  is  in  the  QHKL  matrix  list,  however,  the  module  extracts  each  matrix 
individually  using  the  EXQKK  utility  and  performs  the  multiplication: 

[QZHH]  «  [QHK] [PHIKH] 

and  appends  the  resultant  matrix  onto  QHLL. 

The  matrix  QHJL  is  also  output.  Since  this  matrix  only  requires  a  premultiplication  of  the  input  QKJL 
matrix  list  by  phikh,  it  is  performed  in  one  step  and  the  module  terminates. 

Design  Requirements: 

1.  The  UNSTEADY  module  must  have  been  executed  to  generate  the  aerodynamic  matrices  and  generate 
the  UNMK  entity. 

Error  Conditions: 

None 
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Engineering  Application  Module:  RBCHECK 

Entry  Point:  RDGCHK 


Purpose: 

Tb  compute  the  rigid  body  strain  energies  associated  with  displacements  of  each  support  degree  of 
freedom. 

MAPOL  Calling  Segue  ~ice: 

CALL  RBCHECK  <  BC,  USET(BC)  ,  BGFDT(BC),  [D (BC) ] ,  [KLL] ,  [KSR] ,  [SLR]  ); 

BC  Boundary  condition  number.  (Integer,  Input) 

USET  (BC)  The  unstructured  entity  defining  structural  sets  (Input) 

[KLL]  The  stiffness  matrix  in  the  1-set  degrees  of  freedom  (Input) 

[KRR]  The  stiffness  matrix  in  the  r-set  degrees  of  freedom  (Input) 

[KLR]  The  off-diagonal  1-r  partition  of  the  a-set  stiffness  matrix.(Input) 

Application  Calling  Sequence: 

None 


Method: 

TheRBCHECK  module  begins  by  checking  if  the  USST  entity  contains  any  support  (r-set)  degrees  of 
freedom.  If  not,  the  module  returns.  The  module  continues  by  reading  the  BGPDT  into  memory  and  then 
computing  the  strain  energy  associated  with  the  rigid  body  displacements: 

[X]  =  [KLR]1  [D]  +  [KRR] 


The  X  and  KRR  matrices  are  then  read  into  memory  and  two  normalization  measures  are  computed.  The 
first  is  the  overall  norm  of  each  matrix: 

nr  nr 

Xnorm  —  ]£,  |  Xjj  | 

i=l  j=l 

nr  nr 

KRRnonn  =  £  £  |  KRR ij  | 

*=1  M 

Xnorm 

£matriX  "  KRRnorm 

The  second  is  the  norm  of  each  of  the  nr  columns: 
nr 

■^Jnorm  ””  |  Xij  1 

i=l 


nr 

KXKjnorm  =  |  KRRy 
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X, 

J  aorrs 

coi  ~  xaiT 

*  none 

Thesa  eiror  ratios  and  norms  are  then  printed  out  along  with  the  associated  diagonal  of  x  (the  strain 
energy)  for  each  support  degree  of  freedom. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Engineering  Application  Module:  RECOVA 
Entry  Point:  RECOVA 


Purpose: 

To  recover  the  symmetric  or  asymmetric  f-set  displacements  or  accelerations  if  there  are  omitted  degrees 
of  freedom. 


MAPOL  Calling  Sequence: 

CALL  RECOVA  (  [UA]  ,  [PO]  ,  [GSUBO(BC)],  NRSET,  [AA]  ,  [IiM(BC)],  SYM, 
[KOOINV (BC)  ]  ,  [KOOU (BC)  ]  ,  [PFOA(BC)],  [UF]  ); 


[UA] 

[PO] 

[GSUBO  (BC) ] 
NRSET 
[AA] 

[IEM(BC) ] 

SYM 

[KOOINV  (BC)] 
[KOOU  (BC)  ] 
[PFOA(BC) ] 
[UP] 


Matrix  of  displacements  or  accelerations  in  the  analysis  set  (Input) 

Optional  matrix  of  static  loads  applied  to  omitted  degrees  of  freedom 
(Input) 

Static  condensation  transformation  matrix  (Input) 

Flag  indicating  that  inertia  relief  effects  are  to  be  included  (Integer,  Input) 

Optional  matrix  of  analysis  set  accelerations  for  inertia  relief  (Input) 

Optional  matrix  containing  terms  needed  for  inertia  relief  (Input) 

Optional  symmetry  flag;  =1  if  any  KFF  is  not  symmetric  (Integer,  Input) 

Matrix  containing  the  inverse  of  KOO  for  symmetric  stiffness  matrices  or 
the  lower  triangular  factor  of  KOO  for  asymmetric  matrices  (Input) 

Optional  matrix  containing  the  upper  triangular  factor  of  KOO  for  asym¬ 
metric  stiffness  matrices  (Input) 

The  partitioning  vector  splitting  the  free  degrees  of  freedom  into  the 
analysis  set  and  the  omitted  degrees  of  freedom  (Input) 

Matrix  containing  the  displacements  or  accelerations  for  the  free  degrees 
of  freedom  (Output) 


Application  Calling  Sequence: 
None 


Method: 

The  recova  module  begins  by  checking  if  the  PO  argument  is  nonblank.  If  so,  the  displacements  at  the 
omitted  degrees  of  freedom  due  to  the  loads  at  the  omitted  degrees  of  freedom,  uoo,  are  computed.  These 
computations  depend  on  whether  inertia  relief  and/or  asymmetric  stiffnesses  exist.  If  inertia  relief  is 
required  (NRSET  >  0)  the  loads  on  the  omitted  DOF’s  are  modified  using  the  I  EM  matrix  and  the  analysis 
set  accelerations,  AA;  both  of  which  must  be  input: 

[PO]  ■  [PO]  -  [IEM] [AA] 


The  uoo  terms  are  then  computed  from  the  inverted  KOO  terms  based  on  the  s  YM  flag;  with  the  symmetry 
flag  indicating  whether  the  general  or  symmetric  forward  backward  substitution  is  used: 

[uoo]  *  [KOO] -1  [PO]  using  Forward  Backward  Substitution 
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i-’inally,  the  omitted  displacements,  no,  are  computed  from: 

[UO]  *  [GSUBO]  [UA]  +  [0OO] 

Note  that  the  module  assumes  that  the  correct  set  of  KOOIKV,  KOOU,  IIM,  AA,  and  PO  matrices  are 
supplied  to  match  the  SYM  and  HRSET  flags.  If  the  PO  argument  is  omitted  from  the  calling  sequence, 
the  no  terms  are  computed  directly  from: 

[uo]  »  [GSUBO] [UA] 

with  the  GSUBO  argument  required  to  perform  the  computation.  Note  that  these  computations  are  the 
same  irrespective  of  the  nrset  flag.  Wien  uo  is  complete,  the  module  merges  the  computed  uo  terms 
with  the  supplied  UA  terms  to  form  the  UF  output. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Engineering  Application  Module:  SAERO 

Entry  Point:  SAERO 

Purpose: 

lb  solve  the  trim  equation  for  steady  aeroelastic  trim  analyses  and  to  compute  the  rigid  and  flexible 
stability  coefficients  for  steady  aeroelastic  analyses  and  the  aerodynamic  effectiveness  constraints  for 
constrained  optimization  steady  aerodynamic  analyses. 

MAPOL  Calling  Sequence: 

CALL  SAERO  (  NITER,  BC,  MINDEX,  SOB,  SYM,  QDP,  3TABCF,  BGPDT(BC), 

[LHSA(BC , SOB) ] ,  [RHSA{BC,StJB)  ]  ,  [AAR],  [DELTA (SOB) ] ,  [FRIGID] . 
[R33],  CONST,  AEFLG(SOB),  [AARC] ,  [DELC]  ); 


NITER 

Design  iteration  number  (Integer,  Input) 

BC 

The  current  boundary  condition  (Integer,  Input) 

MINDEX 

Mach  number  index  for  the  current  subscript  value.  (Integer,  Input) 

SOB 

Subscript  number  of  SAERO  subcases  considered  in  this  call. 

(Integer,  Input) 

SYM 

The  symmetry  flag  for  the  current  saero  subcases  (Integer,  Input) 

QDP 

Dynamic  pressure  associated  with  the  current  subscript.  (Real,  Input) 

STABCF 

Relation  of  rigid  stability  coefficient  data  (Input) 

BGPDT (BC) 

Relation  of  basic  grid  point  coordinate  data  (Input) 

[LHSA (BC , SOB) ] 

Matrix  of  modified  inertia  coefficients  (Input) 

[RHSA (BC , SOB) ] 

Matrix  of  applied  load  vectors  reduced  to  the  r-set  (Input) 

[AAR] 

Matrix  of  acceleration  vectors  (Output) 

[DELTA (SOB)] 

Matrix  of  configuration  parameters  (Output) 

[PRIGID] 

Rigid  load  matrix  (Input) 

[R33] 

Reduced  rigid  body  mass  matrix  (Input) 

CONST 

Relation  of  constraint  values  (Input) 

AEFLG(BC) 

The  logical  flag  denoting  presence  of  aeroelastic  constraints 
(Logical,  Output) 

[AARC] 

Matrix  of  structural  accelerations  due  to  unit  configuration  parameters 
for  use  in  sensitivity  evaluation  (output) 

[DELC] 

Matrix  of  "unit"  flight  configuration  parameters  used  to  generate  the 
AARC  accelerations  (output) 
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Application  Calling  Sequence: 

None 

Method: 

The  module  begins  by  bringing  into  memory  the  CASE  entries  associated  with  SAERO  subcases  in  the 
current  boundary  condition.  Then,  the  STABCF  relation  is  read  into  memory  for  the  current  MXKDEX 
value.  The  trim  relation  is  read  for  all  entries  that  havs  the  current  subcript  value  and  other  trim  data 
from  AEROS,  ccneffs,  and  conlink  are  also  read  into  memory. 

Then  an  evaluation  of  the  trim  data  is  done  to  determine  the  number  of  trim  subcases  that  will  be  solved 
during  this  pass  (for  the  current  subscript).  The  AROCHK  utility  is  used  to  evaluate  the  SOPORT  condition 
to  ensure  (again)  that  it  satisfies  the  requirements  of  the  TRIM  solver  and  to  get  the  names  and  DOFs 
of  the  supported  degrees  of  freedom.  Then,  after  creating  needed  scratch  entities,  the  grand  loop  on  the 
trim  subcases  begins. 

Each  trim  subcase  must  be  solved  separately  because  of  the  options  for  control  effectiveness  and  control 
linking.  The  first  step  is  to  determine  which  trim  entries  are  associated  with  the  current  subcase  (note 
all  are  associated  with  tho  current  subscript).  Once  the  trim  id  of  the  current  case  is  known,  the  CASE 
relation  data  are  searched  to  determine  the  subcase  number  (1  to  n  over  all  SAERO  entries  in  CASE  for 
each  BC).  Then  the  arolnk  routine  is  called  to  assemble  a  linking  matrix  of  control  effectiveness  factors 
and  linking  relationships  for  the  current  subscript  such  that: 

{8}  »  [TLINK]  *  DELRED 

where  the  DELRED  matrix  is  reduced  to  only  the  active  trim  parameters  and  the  effectiveness  factors 
have  been  included.  Then  the  rigid  and  flexible  loads  are  hit  with  the  linking  matrix  to  reduce  the 
problem  to  the  relevant  configuration  parameters: 

P2RED  =  P2  *  TLINK 


RHSRED  *  RHS  *  TLINK 


P2RED  and  RHSRED  contain  one  row  for  each  structural  acceleration  and  one  column  for  each  label  on 
the  trim  entry  This  means  that  the  total  number  of  stability  parameters  (either  fixed  or  free)  is  the 
number  of  columns  in  P2  and  RHS.  Further,  the  order  of  the  parameters  is  the  order  given  on  the  TRIM 
tuples. 

Now  the  trim  equations  can  be  assembled.  From  the  input,  we  have  the  relationship 


LHS,„  LH3  ’ 
tt  fk 

LHS.  . 

k£  kk_ 

^Scnown 

RHSfu  RHSf,‘ 

DEV 

RHS^u  RHS)t8 

DEL 

s 

Where: 

Represents: 

F+K 

Number  of  SUPORT  point  DOFs 

F 

Set  of  free  accelerations,  AR 

K 

Set  ofknown(FlXED)  accelerations,  AR 

U+S 

Number  of  aero  parameters 

V 

Set  of  unknown  parameters 

a 

Set  of  set( fixed)  parameters 
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These  equations  must  be  rearranged  to  get  free  accelerations  and  unknown  delta’s  on  the  same  side  of 
the  equation: 


"“Wfu' 

[— LHSk)t  RHS,,* 

■"St" 

LHSu, 

.  °ELu  . 

[-LHSsk  RHS„ 

«L. 

and  we  must  handle  the  degenerate  case  where  all  accelerations  or  all  delta’s  are  known. 

Following  rearrangement  of  the  equations,  the  unknowns  are  solved  for  in  the  ARTRMS/D  routine.  First 
tht  rigid  masses  and  loads,  P2RED  andMRR  are  used  to  obtain  the  rigid  trim  and  then  the  flexible  inputs 
RHSRED  and  lbs  are  used  for  the  "real"  solution. 

Then,  the  flexible  results  are  unscrambled  and  the  rigid  body  accelerations  (either  input  on  the  trim 
or  output  firm  the  solution  of  the  above)  are  stored  on  the  AAR  matrix  and  the  same  is  dene  with  the 
trim  parameters  after  the  TLINK  matrix  is  used  to  recover  the  full  vector  from  the  reduced  3et.  Then 
the  results  for  the  rigid  and  flexible  trim  are  printed. 

Only  if  the  print  is  requested  or  if  constraints  are  applied  are  the  stability  coefficients  computed.  These 
data  are  recomputed  in  each  subcase  because  the  effectiveness  terms  affect  tne  stability  derivative 
outputs.  The  AR3CFS/D  module  is  called  to  compute  the  flexible  data  from  the  forces  on  the  support 
degrees  of  freedom  due  to  the  unit  configuration  parameters: 

[F]  =  [MRR]  [LHS]"1  [RHS] 

The  P2  matrix  contains  the  same  information  for  the  rigid  aerodynamic  loads  (computed  in  the  MAPOL 
sequence).  These  data  are  then  normalized  and  the  stability  coefficient  table  stored  into  memory.  Once 
complete,  the  stability  coefficient  table  is  printed  using  the  effectiveness  factors  and  linking  terms  to 
assemble  the  "dependent"  coefficients  and  factor  all  coefficients  according  to  the  user  input. 

Finally,  using  the  in-core  table  of  derivatives,  the  ARCONS/D  submodule  is  called  to  evaluate  the 
constraints  for  the  current  subcase.  These  constraints  are  evaluated  from  the  stability  coefficient  table 
but,  to  prepare  for  eventual  sensitivity  computations,  the  additional  outputs  AEFLG,  aarc  and  DELC  aie 
needed  The  first  is  a  logical  flag  to  indicate  to  the  MAPOL  sequence  that  the  AARC  and  DELC  matrices 
are  full.  The  AARC  matrix  and  DELC  matrix  contain  one  or  more  columns  for  each  constraint  (appended 
in  the  order  the  constraints  are  evaluated).  The  aarc  contains  the  accelerations  of  the  support  DOFs 
due  to  the  unit  configuration  parameter  vectors  in  DELC.  This  pair  of  matrices  will  allow  the  computation 
of  the  derivative  of  the  accelerations  due  to  the  unit  parameters  which  is  an  essential  ingredient  in  the 
sensitivity  computation. 

For  lift  effectiveness  constraints 

aarc  - 1  column  due  to  unit  ALPHA 

delc  - 1  column  containing  a  unit  alpha  with  all  others  0.0 

For  aileron  effectiveness  constraints 

aarc  2  columns;  the  first  for  unit  surface  rotation  and  the  second  for  unit  roll  rate  (PRATE). 
DELC  2  columns  containing  a  unit  rotation  of  the  named  surface  and  the  second  a  unit  PRATE 
For  stability  coefficient  constraints  (DCONSCF) 

AARC  - 1  column  due  to  unit  PARAMETER  where  PARAMETER  is  that  named  on  the  constraint  entry 
delc  - 1  column  containing  a  unit  PARAMETER  with  all  others  0.0 
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DCCNThm  are  evaluated  at  this  time,  but  do  not  require  any  pseudodisplacements  for  sensitivity 
evaluation.  The  pseudodisplacements  are  those  which  arise  due  to  the  unit  accelerations  that  arise  due 
to  unit  configuration  parameters. 

After  the  stability  coefficients  (and  constraints)  are  computed  and  printed,  the  rigid  and  flexible  trim 
results  are  printed  and  the  module  repeats  the  entire  process  for  all  the  subcases  that  are  associated 
with  the  current  SOEscript.  Then  the  module  terminates. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Engineering  Application  Module:  SAERODKV 

Entry  Point:  SARODR 

Purpose: 

MAPOL  director  for  steady  aeroelastic  analyses. 

MAPOL  Calling  Sequence: 

CALL  SAERODRV  (BC,  SOB,  LOOP,  MINDEX,  SYM,  MACE,  QDP,  PRINT  ); 

bc  Boundary  Condition  number.  (Integer,  Input) 

sob  Current  Mach  number  subscript  number.  (Integer,  Input) 

loop  Logical  flag  indicating  whether  another  subscript  is  required  to  complete 

the  set  of  all  subcases.  (Logical,  Output) 

mindex  Mach  number  index  associated  with  the  current  subscript. 

(Integer,  Output) 

sym  SYMmetry  flag  for  the  current  subscript. 

*  1  symmetric 
=  -1  Antisymmetric 
(Integer,  Output) 

MACH  Mach  number  associated  with  the  current  subscript.  (Real,  Output) 

QDP  Dynamic  pressure  associated  with  the  currant  subscript.  (Real,  Output) 

PRINT  Optional  print  flag  indicating  that  the  summary  of  trim  cases  associated 

with  the  current  pass  (subscript)  is  to  be  printed  to  the  standard  output. 
(In  the  standard  sequence,  print  is  used  only  during  analysis  not  during 
sensitivity  analysis).  (Optional,  Integer,  Input) 


PRINT 


sequence 


Method: 

First  the  case  relation  is  read  to  determine  the  TRIM  ids  and  SYMmetries  of  all  saero  cases  in  the 
current  boundary  condition.  If  any  exist,  the  TRIM  relation  is  opened  and  read  into  memory.  Each  trim 
entry  referenced  in  CASE  is  then  compressed  into  a  format  containing  the  trim  id,  Mach  number, 
dynamic  pressure,  trim  type,  Mach  number  index,  subscript  and  3ubcase  id. 

Once  these  data  are  collected,  the  CASE  tuples  read  into  memory  are  looped  over  to  choose  which  TRIM 
cases  are  to  be  analyzed  for  this  subscript  value.  There  are  four  steps  in  choosing  the  proper  trim  cases: 

( 1)  Take  the  first  SAERO  subcase  in  CASE  that  has  not  been  done  on  an  earlier  pass  —  cases  already 
analyzed  will  reference  trims  with  a  "subscript"  value  that  is  not  "null"  (uninitialized)  and  that  is 
less  than  the  current  value  of  SUB  —  on  the  first  design  iteration  all  subscript  values  will  be  "null" 

(2)  Once  the  parent  case  is  known,  choose  that  case  and  all  others  with  the  same  Mach,  QDP  and 
TRMTYP 


(3)  Update  the  "subcript"  attribute  in  TRIM  to  mark  all  the  cases  that  are  being  processed.  Also  load 
the  S0BID  to  assist  in  re-merging  the  answers  into  CASE  subcase  order 
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(4)  Check  if  any  more  saero  subcases  need  to  be  processed  and  set  the  "loop"  flag 


After  these  steps  have  been  completed,  if  the  print  flag  is  nonzero,  a  summary  of  the  selected  TRIMs 
in  printed  to  the  output  file. 

Design  Requirements: 

1.  The  trim  relation  is  assumed  to  contain  NULL  values  for  subscrpt  on  the  first  subscript  of  the  first 
design  iteration  (for  OPTIMIZE  boundary  conditions)  and  for  the  first  subscript  of  all  ANALYZE  boundary 
conditions. 

Error  Conditions: 

None 
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Engineering  Application  Module:  SAEROMRG 
Entry  Point:  SAROMR 


Purpose: 

Merges  the  static  aero  results  for  each  subscript  (stored  in  the  matrix  [MATSOB] )  into  the  [MATOOT] 
matrix  in  case  order  rather  than  subscript  order  for  the  bc’th  boundary  condition. 

MAPOL  Calling  Sequence: 

CALL  SAEROMRG  (  BC,  SOB,  [MATOUT]  ,  [MATSOB]  )  ; 

BC  Current  boundary  condition  number.  (Input,  Integer) 

SOB  Current  Mach  number  subscript.  (Input,  Integer) 

[MATOUT]  Merged  output  matrix  reordered  to  be  in  CASE  order  for  the  current 

boundary  condition.  (Input  and  Output) 

[MATSOB]  Generic  input  matrix  containing  data  for  the  current  subscript  value  in 

TRIM  id  order  of  TRIM  cases  associated  with  the  current  subscript.  (Input) 


None 


Method: 

First  the  CASE  relation  is  read  to  retrieve  the  trim  id's  for  the  SAERO  subcases  in  the  current  boundary 
condition.  The  the  TRIM  relation  is  read  to  obtain  the  subcase  numbers  associated  with  each  trim  id 
having  the  current  SOBscript  value. 

Then  the  matsob  and  matoot  matrices  are  opened.  If  matout  is  uninitialized  or  if  SOB  -  1,  it  is 
initialized  (flushed  end  the  number  of  rows,  precision  and  form  set  to  those  ofMATSUB.  If  MATOOT  already 
exists  and  has  data  in  it,  a  scratch  matrix  is  created  to  hold  the  final  merged  data. 

For  each  SAERO  CASE  entry  for  the  current  boundary,  the  TRIM  data  are  searched  to  determine  the 
subscript  number  associated  with  the  subcase.  If  the  subscript  is  less  than  sob,  a  column  from  MATOOT 
will  be  taken  (it  was  stored  there  on  an  earlier  pass).  If  the  subscript  is  equal  to  SOB,  it  will  be  stored 
on  the  output  matrix  from  MATSOB.  If  greater  than  sob,  it  is  ignored  till  later  passes. 

Once  a  column  is  identified  as  active  in  MATSOB  (PGAA  indicates  active  and  subscript = sob),  an  additional 
check  is  made  to  see  if  the  column  is  active  in  P60A.  Only  those  columns  that  are  active  in  pgoa  are 
copied  to  MATOOT.  This  filtering  is  done  to  limit  the  amount  of  computational  effort  in  the  stress,  strain 
and  displacement  constraint  sensitivity  computations  that  proceed  using  the  MATOOT  matrix.  The 
MATSOB  columns  that  are  active  due  to  DCCNTRM  constraints  are  no  longer  needed  as  these  sensitivities 
are  assumed  to  have  been  computed  already  in  the  AEROSENS  module. 

Once  the  final  matrix  is  formed,  if  MATOOT  had  had  data  in  it,  the  name  of  the  scratch  matrix  that  was 
loaded  is  switched  with  that  of  MATOOT.  The  scratch  entity  is  then  destroyed. 
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Design  Requirements: 

1.  The  assumption  is  that  each  matsub  matrix  contains  the  results  from  the  "S0B"th  subscript  value  in 
the  order  the  trim  id’s  for  that  SUB  appear  in  the  TRIM  relation. 

2.  The  same  MATOOT  matrix  must  be  passed  into  the  arosnsmr  module  on  each  call  since  the  columns 
associated  with  earlier  subscript  values  are  read  from  matout  into  a  scratch  entity.  The  merged  matrix 
that  results  .a  then  replaces  the  input  MATOUT. 

3.  The  AEROSENS  module  is  called  upstream  of  the  AROSHSMR  module  to  process  active  dcontkm 
constraints  for  the  current  subscript.  Thus,  those  columns  that  sure  active  only  for  DCONTRM  constraints 
may  be  filtered  out  for  the  downstream  processing  of  stress,  strain  and  displacement  constraints. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Engineering  Application  Module:  SCEVAL 

Entry  Point:  SCEVAL 

Purpose: 

lb  compute  the  stress  and/or  strain  constraint  values  for  the  statics  or  steady  aeroelastic  trim  analyses 
in  the  current  boundary  condition. 

MAFOL  Calling  Sequence: 

CALL  SCEVAL  (  NITER,  BC,  [US(BC)],  [SMAT]  ,  TREE,  [GLBSIG]  ,  CONST,  DSCFLG 


NITER 

Design  iteration  number  (Integer,  Input) 

BC 

Boundary  condition  identification  number  (Integer,  Input) 

[UG(BC)] 

The  matrix  of  global  displacements  for  ail  static  applied  loads  in  the  cur¬ 
rent  boundary  condition  (Input) 

[SMAT] 

Matrix  entity  containing  the  sensitivity  of  the  stress  and  strain  compo¬ 
nents  to  the  global  displacements  (Input) 

TREF 

Unstructured  entity  containing  the  element  reference  temperature  (Input) 

[GLBSIG] 

Matrix  of  stress/strain  components  for  all  the  applied  stress  constraints 
for  the  current  boundary  condition  (Output) 

CONST 

Relation  of  constraint  values  (Const) 

DSCFLG 

The  discipline  flag  (Integer,  Input) 

•  0  statics 

>  0  static  aeroelasticity 

Application  Calling  Sequence: 

None 

Method: 

The  sceval  module  begins  by  determining  if  there  are  any  stress  constraints  applied  by  checking  if  any 
DCCNVM,  DCONVMM,  DCONVMP,  DCONTW,  DCONTHM,  DCONTWP,  DCONEP,  DCONEEM,  DCONEPP,  DCONFT, 
dconfim,  DCONFTP  bulk  data  entries  were  included  in  the  input  data  stream.  If  any  are  found, 
execution  continues. 

First  the  CASE  relation  is  read.  Then,  if  the  call  is  associated  with  saero  disciplines,  the  TRIM  relation 
is  read  to  associate,  for  each  subcase,  the  subcase  id  and  the  subscript  id.  Then  an  in-core  table  is  formed 
that  contains,  for  the  subcases  in  this  boundary  condition  the  DISFLAG,  subscript,  and  thehmid.  The 
latter  is  for  thermal  load  corrections  to  the  stresses  and  strains.  If  any  thermal  load  cases  were  found, 
the  gridtemp  and  tref  entities  are  is  opened. 

If  the  current  boundary  condition  is  the  first  with  stress  or  strain  constraints,  the  running  constraint 
type  count  variables  are  reinitialized  for  the  current  design  iteration.  This  type  count  provides  a  link 
between  the  ACTCON  print  of  design  constraints  and  the  debug  print  option  supported  by  the  SCEVAL 
module.  If  any  thermal  loads  exist  for  the  current  boundary  condition,  the  GRIDTEMP  and  TREF  entities 
are  brought  into  memory  to  be  available  for  the  computation  of  the  stress-free  thermal  strain  correction 
to  the  element  stresses.  Once  these  preparations  have  been  made,  the  SMAT  matrix  of  stress/strain 
sensitivities  and  the  glbsig  matrix  are  opened  and  the  GLBSIG  matrix  is  positioned  to  the  proper 
column  to  pack  additional  stress/strain  components.  Note  that  the  glbsig  matrix  stores  all  the  columns 
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associated  with  the  current  boundary  condition  since  they  are  required  for  the  constraint  sensitivity 
computations. 

Finally,  the  ug  matrix  of  global  displacements  is  opened.  For  each  column  in  the  UG  matrix  associated 
with  a  set  of  physical  displacements  (the  SAERO  discipline  generates  psuedo-displacements  associated 
with  aeroelastic  effectiveness  constraints  that  are  ignored  by  sceval),  the  matrix  product 

[®£A]  «  [SMAT]{UG} 

is  calculated  to  obtain  the  component  stress  or  strain  values  for  each  constrained  element.  Having 
calculated  and  stored  in  core  these  values,  the  element  dependent  constraint  evaluation  routines  are 
called  to  process  each  constraint.  Note  that  the  order  in  which  the  element  routines  are  called  must  be 
the  same  as  the  order  the  smat  columns  were  formed.  That  order  is: 

1.  Bar  elements,  barsc 

2.  Isoparametric  quadrilateral  membrane  elements,  QD1SC 

3.  Quadrilateral  bending  plate  elements,  QD4SC 

4.  Rod  elements,  rodsc 

5.  Shear  panels,  sbrsc 

6.  Triangular  bending  plate  elements,  TR3SC 

7.  Triangular  membrane  elements,  TRMSC 

On  the  first  pass  through  the  element  dependent  routines,  all  the  xxaatEST  tuples  (i.e.,  rodest  and 
TRMEMEST)  with  nonzero  stress/strain  constraint  flags  are  retrieved  from  the  data  base.  For  subsequent 
passes,  this  information  is  used  directly  from  core.  Each  constraint  is  evaluated  in  turn  with  the  stress 
components  modified  by  the  thermal  stress  correction  if  the  displacement  field  includes  thermal  strain 
effects.  The  const  relation  is  loaded  with  one  tuple  for  each  constraint  as  they  are  processed.  When  all 
the  constraints  have  been  evaluated  for  the  current  loading  condition,  the  adjusted  stress/strain 
constraint  terms  are  packed  to  the  glbsig  matrix. 

Design  Requirements: 

1.  The  smat,  gridtemp  and  tref  entities  must  exist. 

2.  The  case  relation  must  be  complete  from  solution. 

Error  Conditions: 

1.  A  zero  material  allowable  may  cause  division  by  zero  in  the  computation  of  some  of  the  constraints. 
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Engineering  Application  Module:  SOLUTION 

Entry  Point:  SOLUTION 

Purpose: 

Tb  interpret  the  solution  control  packet. 

MAPOL  Calling  Sequence: 

CALL  SOLUTION  <  NOMOPTBC,  NBNDCOND,  MP3,  MPE,  OCS ,  OCE,  FSDS,  FSDE,  MAXI  TER, 
MOVLIM,  WINDOW,  OOOVLIM,  ALPHA,  CNVRGLIM,  NRFAC ,  EPS  ); 


NOMOPTBC 

NBNDCOND 

MPS 

MPE 

OCS 

OCE 

FSDS 

FSDE 

MAXI TER 


Number  of  optimization  boundary  conditions  (Integer,  Output) 

Tbtal  number  of  optimization  and  analysis  boundary  conditions  (Integer, 
Output) 

The  first  iteration  to  use  math  programming  (Integer,  Output) 

The  last  iteration  to  use  math  programming  (Integer,  Output) 

The  first  iteration  to  use  optimality  criteria  (Integer,  Output) 

The  last  iteration  to  use  optimality  criteria  (Integer,  Output) 

The  first  iteration  to  use  FSD  (Integer,  Output) 

The  last  iteration  to  use  FSD  (Integer,  Output) 

The  maximum  number  of  allowable  iterations  (Integer,  Output) 


MOVLIM 

WINDOW 


OCMOVLIM 

ALPHA 


Limit  on  how  much  a  design  variable  can  move  for  this  iteration  in  using 
math  programmingfReal,  Output) 

The  window  around  the  zero  in  which  the  movlim  bound  is  overridden  to 
allow  the  local  variable  to  change  sign.  If  window  *  0 . 0,  the  local  vari¬ 
able  may  not  change  sign.  If  WINDOW  is  nonzero,  the  half  width  of  a  band 
around  zero,  EPS  is  computed 

EPS  “  WINDOW/ 100  *  MAX  (  ABS  (TMXN)  ,  ABS(IMIN)  ) 

If  the  local  variable  falls  within  the  band,  the  new  minimum  or  maximum 
for  the  current  iteration  is  changed  to  lie  on  the  other  side  of  zero  from 
the  local  variable.  The  bandwidth  EPS  is  a  percentage  of  the  larger  of 
TMAX  or  TMIN  where  window  specifies  the  percentage.  (Real,  Output) 

Limit  on  how  much  a  design  variable  can  move  for  this  iteration  in  using 
optimality  critera  (Real,  Output) 

Exponential  move  limit  for  the  FSD  algorithm  (Real,  Output) 


CNVRGLIM  Relative  percent  change  in  the  objective  function  that  indicates  approxi¬ 

mate  problem  convergence  (Real,  Output) 

NRFAC  Determines  the  minimum  number  of  retained  constraints  equal  to 

NRFAC*NDV  (Real,  Output) 

EPS  A  second  criteria  for  constraint  retention.  All  constraints  greater  than  or 

equal  to  EPS  will  be  retained  (Real,  Output) 
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Application  Calling  Sequence: 

None 

Method: 

The  SOLUTION  module  interprets  the  solution  control  statements  and  loads  the  resultant  information 
to  the  CASE  relation.  On  completion  of  the  routine,  the  total  number  of  all  boundary  conditions,  the 
number  of  analysis  boundary  conditions  and  the  user’s  optimization  strategy  are  output  to  the  executive 
sequence  to  direct  the  MAPOL  execution  path. 

Design  Requirements: 

1.  A  Solution  Control  packet  must  be  included  in  the  input  data  stream. 

Error  Conditions: 

1.  Syntax  errors  and  inconsistent  or  illegal  solution  control  requests  are  flagged  and  the  execution  is 
terminated. 
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Engineering  Application  Module:  SPLINE  S 

Entry  Point:  SPLINE 


m 


Purpose: 

Generates  the  interpolation  matrices  that  relate  displacements  and  forces  between  the  structural  and 
steady  aerodynamic  models. 

MAPOL  Calling  Sequence: 

CALL  SPLINES  (  GSIZEB,  GECMSA,  ASCCMPS,  AEROS ,  [GTKG]  ,  [GSTKG]  ); 

The  number  of  degrees  of  freedom  in  the  set  of  all  structural  GRID  and 
SCALAR  points.  (Integer,  Input) 

A  relation  describing  the  aerodynamic  boxes  for  the  steady  aerodynamics 
model.  The  location  of  the  box  centroid,  normal  and  pitch  moment  axis 
are  given.  It  is  used  in  splining  the  aerodynamics  to  the  structure  and  to 
map  responses  back  to  the  aerodynamic  boxes.  (Input) 

A  relation  describing  aerodynamic  components  for  the  steady  aerodynam¬ 
ics  model.  It  is  used  in  splining  the  aerodynamics  to  the  structural  model. 
(Input) 

A  relation  containing  the  definition  of  the  aerodynamic  coordinate  sys¬ 
tem.  (Input) 

The  matrix  of  splining  coefficients  relating  the  aerodynamic  pressures  to 
forces  at  the  structural  grids.  (Output) 

The  matrix  of  splining  coefficients  relating  the  structural  displacements 
to  the  streamwise  slopes  of  the  aerodynamic  boxes.  (Output) 

Application  Calling  Sequence: 

None 

Method: 

All  the  SPLINE1,  SPLINE2  and  ATTACS  data  are  read  and  those  associated  with  the  steady  aerodynamic 
model  as  described  by  the  aeccmps  entity  are  used  to  assemble  a  list  of  aerodynamic  boxes  and  structural 
grids  for  each  spline.  The  GECMSA  relation  is  used  to  obtain  the  basic  coordinates  of  the  aerodynamic 
boxes  and  the  BGPDT  relation  is  used  to  obtain  the  locations  of  the  structural  grids.  The  spline  matrix 
consisting  of  two  columns  (displacement  and  slope)  for  each  aerodynamic  box  and  6  rows  for  each 
structural  grid  is  then  assembled  for  the  aerodynamic  boxes  and  structural  grids  attached  to  the  spline. 

The  spline  matrix  is  then  expanded  to  include  two  columns  for  each  aerodynamic  box  in  the  steady 
aerodynamic  model  and  GSIZEB  rows.  It  is  then  split  into  two  pieces  with  each  odd-numbered  column 
(displacement)  merged  with  previously  processed  splines  to  form  the  GTKG  matrix  and  each  even 
numbered  (slope)  column  merged  to  form  GSTKG.  The  process  is  repeated  until  all  splines  have  been 
completed.  The  final  matrices  are  returned  to  the  MAPOL  sequence. 


GSIZEB 

GECMSA 

AECCMPS 

AERO  3 

[GTKG] 

[GSTKG] 
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Design  Requirements: 
None 


Error  Conditions: 

1.  Each  aerodynamic  box  may  appear  on  only  one  SPLINK1,  SPLINE2  or  ATTACH  entry  although  not  all 
boxes  need  appear.  Missing  boxes  will  not  influence  the  aeroelastic  response. 

2.  Missing  structural  grids  or  aerodynamic  elements  appearing  on  the  spline  definitions  will  be  flagged. 
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Engineering  Application  Module:  SPLINEU 


SPLINE 


Generates  the  interpolation  matrix  that  relate  displacements  and  forces  between  the  structural  and 
unsteady  aerodynamic  models. 

MAPOL  Calling  Sequence: 

CALL  SPLINEU  (  GSIZEB,  GECMOA,  AECCMPU,  AERO,  [UGTXG]  ) ; 

gsizeb  The  number  of  degrees  of  freedom  in  the  set  of  all  structural  GRID  and 

SCALAR  points.  (Integer,  Input) 

GECMDA  A  relation  describing  the  aerodynamic  boxes  for  the  unsteady  aerodynam¬ 

ics  model.  The  location  of  the  box  centroid,  normal  and  pitch  moment  axis 
are  given.  It  is  used  in  splining  the  aerodynamics  to  the  structure  and  to 
map  responses  back  to  the  aerodynamic  boxes.  (Input) 

aeccmpu  A  relation  describing  aerodynamic  components  for  the  unsteady  aerody¬ 

namics  model.  It  is  used  in  splining  the  aerodynamics  to  the  structural 
model.  (Input) 

AERO  A  relation  containing  the  definition  of  the  aerodynamic  coordinate  sys¬ 

tem.  (Input) 

[ugtkg]  The  matrix  of  splining  coefficients  relating  the  aerodynamic  pressures  to 

forces  at  the  structural  grids  and  relating  the  structural  displacements  to 
the  streamwise  slopes  of  the  aerodynamic  boxes.  (Output) 


alication  Calling  Sequence: 


None 


Method: 

All  the  spline  1,  SPLINE2  and  ATTACH  data  are  read  and  those  associated  with  the  unsteady  aerody¬ 
namic  model  as  described  by  the  aeccmpu  entity  are  used  to  assemble  a  list  of  aerodynamic  boxes  and 
structural  grids  for  each  spline.  The  OKCMDA  relation  is  used  to  obtain  the  basic  coordinates  of  the 
aerodynamic  boxes  and  the  BGPDT  relation  is  used  to  obtain  the  locations  of  the  structural  grids.  The 
spline  matrix  consisting  of  two  columns  (displacement  and  slope)  for  each  aerodynamic  box  and  6  rows 
for  each  structural  grid  is  then  assembled  for  the  aerodynamic  boxes  and  structural  grids  attached  to 
the  spline. 


The  spline  matrix  is  then  expanded  to  include  a  2  columns  for  each  aerodynamic  box  in  the  unsteady 
aerodynamic  model  and  GSIZEB  rows.  It  is  then  merged  with  previously  processed  splines.  The  process 
is  repeated  until  all  splines  have  been  completed.  The  final  [UGTKG]  matrix  is  returned  to  the  MAPOL 
sequence. 
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Design  Requirements: 


None 

Error  Conditions: 

1.  Each  aerodynamic  box  may  appear  on  only  one  splinei,  SPLINB2  or  attach  entry  although  not  all 
boxes  need  appear.  Missing  boxes  will  not  influence  the  aeroelastic  response. 

2.  Missing  structural  grids  or  aerodynamic  elements  appearing  on  the  spline  definitions  will  be  flagged. 
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Engineering  Application  Module:  STEADY 


STEADY 


lb  perform  preface  aerodynamic  processing  for  planar  steady  aerodynamics. 

MAPOL  Calling  Sequence: 

CALL  STEADY  (  MIND  EX,  LOOP,  ABCOMPS,  GEOMSA,  SIABCF,  [AICMAT  (MINDEX)  ]  , 

[AAICS4AT  (MINDEX)  ]  ,  [AIRFRC  (MINDEX)  ]  ,  AEROGEOM,  CAROGEOM  )  ; 

Mach  number  index  for  the  current  pass.  Controls  which  Mach  Num¬ 
ber/symmetry  conditions  will  be  processed  in  this  pass  of  STEADY.  One 
pass  for  each  unique  Mach  number  will  be  performed  with  MINDEX  incre¬ 
menting  by  one  until  steady  returns  LOOP*false.  (Input) 

A  logical  flag  set  by  STEADY  to  indicate  whether  additional  MINDEX  sub¬ 
scripts  are  needed  to  complete  the  processing  of  all  the  Mach  number/sym¬ 
metry  conditions  on  all  the  TRIM  entries.  One  pass  for  each  unique  Mach 
number  will  be  performed  with  mindex  incrementing  by  one  until 
steady  returns  LOOP*FALSE.  (Output) 

AE comps  A  relation  describing  aerodynamic  components  for  the  planar  STEADY 

aerodynamics  MODEL.  It  is  used  in  splining  the  aerodynamics  to  the  struc¬ 
tural  model.  (Output) 

GECMSA  A  relation  describing  the  aerodynamic  boxes  for  the  planar  STEADY  aero¬ 

dynamics  MOOKL.  The  location  of  the  box  centroid,  normal  and  pitch  mo¬ 
ment  axis  are  given.  It  is  used  in  splining  the  aerodynamics  to  the 
structure  and  to  map  responses  back  to  the  aerodynamic  boxes.  (Output) 

A  relation  of  rigid  stability  coefficients  for  unit  configuration  parameters. 
The  rigid  coefficients  are  stored  in  STABCF  and  the  corresponding  distrib¬ 
uted  forces  are  stored  in  AIRFRC.  The  stabcf  relation  is  used  to  pick  the 
appropriate  rigid  loads  from  AIRJRC  when  performing  the  aeroelastic 
trim  as  well  as  for  retrieving  the  RIGID/DIRECT  stability  coefficients  for 
each  configuration  parameter.  (Output) 

Matrix  containing  the  STEADY  aerodynamic  influence  coefficients  for  SYM- 
metric  Mach  numbers  (Output) 

[AAlCMAT  (MINDEX)  ]  Matrix  containing  the  steady  aerodynamic  influence  coefficients  for  anti- 
SYMmetric  Mach  numbers.  (Output) 

[AIRFRC  (MINDEX)  3  Matrix  containing  the  aerodynamic  forces  for  unit  configuration  parame¬ 
ters  for  the  current  Mach  number  index.  If  both  SYMmetric  and  antiSYM- 
metric  conditions  exist  for  the  Mach  number,  both  sets  of  configuration 
parameters  will  coexist  in  AIRFRC.  (Output) 

AERDGECS4  A  aerodynamic  geometry  relation  output  only  for  geometry  checking.  The 

"grids"  defined  in  aerosecm  are  "connected"  to  2-node  (RODs)  and  4-node 
(quads)  elements  in  the  carogeom  in  such  a  way  as  to  emulate  the  struc¬ 
tural  MODEL.  ICE  may  then  be  used  to  punch  an  equivalent  structural 
MODEL  to  allow  graphical  presentation  of  the  STEADY  aero  model. 


STABCF 


[AICMAT  (MINDEX)  ] 


MINDEX 


LOOP 
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CARO G£  CM 


A  aerodynamic  geometry  relation  output  only  for  geometry  checking.  The 
"grids"  defined  in  AEROSECM  are  "connected"  to  2-node  (rods)  and  4-node 
(quads)  elements  in  the  carogecm  in  such  a  way  as  to  emulate  the  struc¬ 
tural  MODEL.  ICE  may  then  be  used  to  punch  an  equivalent  structural 
model  to  allow  graphical  presentation  of  the  steady  aero  model. 

Application  Calling  Sequence: 

None 

Method: 

The  steady  preface  module  performs  initial  aerodynamic  processing  for  planar  steady  aerodynamics. 
It  is  driven  by  ths  the  TRIM  data  present  in  the  bulk  data  packet  and  the  SAERO  disciplines  in  the  CASE 
relation.  The  CASE  relation  provides  the  symmetries  while  the  TRIM  relation  provides  the  Mach 
numbers.  Only  if  SAERO  disciplines  are  in  CASE  is  any  processing  done  and  both  TRIM  and  AEROS  entries 
must  be  found. 

On  each  call,  the  passdf  submodule  is  called  to  determine  the  set  of  all  Mach  numbers  and,  for  each 
Mach  number,  whether  symmetric,  antisymmetric  or  both  boundary  conditions  are  to  be  applied.  Having 
determined  all  unique  Mach  numbers,  the  passdf  then  determines  the  MiNDEX’th  Mach  number  in 
numerical  order  (lowest  to  highest)  and  that  is  then  processed.  If  the  chosen  Mach  number  is  the  last 
one,  the  loop  flag  is  set  to  false  to  tell  the  MAPOL  sequence  that  no  more  calls  are  needed. 

On  the  first  call  (determined  by  MINDEX-1)  the  STEADY  module  computes  the  planar  steady  aerody¬ 
namic  geometry  in  calls  to  gecm.  It  then  processes  the  current  Mach  number  and  stores  the  resultant 
Ale  terms  in  the  AICMAT  and/or  AAICMAT  entity  (depending  on  the  symmetry  options)  and  in  the 
resultant  rigid  forces  in  the  airfrc  matrix.  The  STA8CF  relation  is  loaded  for  the  current  MINDEX  value 
with  the  symmetric  and  antisymmetric  stability  derivatives  in  the  same  order  that  the  AIRFRC  matrix 
columns  are  loaded.  Hence,  the  stabcf  relation  points  to  the  corresponding  airfrc  column. 

Design  Requirements: 

1.  The  steady  module  interacts  with  the  executive  in  that  the  loop  variable  is  output  on  the  first  call 
and  the  module  expects  to  be  called  again  as  long  as  LOOP  is  true.  For  each  time  called,  the  mindex 
parameter  should  be  unique  although  it  need  not  be  monotonically  increasing.  The  MINDEX  value  must 
be  1  on  the  first  call  to  ensure  that  the  geometiy  processing  is  done. 

Error  Conditions: 

1.  Errors  in  the  steady  aerodynamic  models  or  TRIM  specifications  are  flagged. 
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Engineering  Application  Module:  STEADYNP 


Entry  Point:  STDYNP 


Purpose; 

Non-planar  steady  aeroelastic  analysis  preface. 

MAPOL  Calling  Sequence: 

CALL  STEADYNP  (  NONPONLY,  AECCMPS,  GEOMSA,  STABCF,  [AIRFORCE],  AEROGECM, 
CARO SE CM,  QAGRDLOD  ) ; 


NONPONLY 


AECCMPS 

QECMSA 


STABCF 


[AIRFORCE] 


AEROGECM 


CARO GE  CM 


OAGRDLOD 


A  logical  flag  returned  to  the  MAPOL  sequence  that  is  true  if  the  only  dis¬ 
ciplines  in  the  CASE  relation  are  nonplanar  static  aerodynamics  subcases. 
If  so,  the  MAPOL  sequence  should  terminate  since  there  is  no  further 
steps  to  be  taken.  (Output) 

A  relation  describing  aerodynamic  components  for  the  nonplanar  STEADY 
aerodynamics  model.  (Output) 

A  relation  describing  the  aerodynamic  boxes  for  the  nonplanar  steady 
aerodynamics  model.  The  location  of  the  box  centroid,  normal  and  pitch 
moment  axis  are  given.  (Output) 

A  relation  of  rigid  stability  coefficients  for  unit  configuration  parameters. 
The  rigid  coefficients  are  stored  in  stabcf  and  the  corresponding  distrib¬ 
uted  forces  are  stored  in  airfrc.  The  stabcf  relation  is  used  to  pick  the 
appropriate  rigid  loads  from  AIRFRC  when  performing  the  aeroelastic 
trim  as  well  as  for  retrieving  the  RIGID/DIRECT  stability  coefficients  for 
each  configuration  parameter.  (Output) 

Matrix  containing  the  aerodynamic  forces  for  unit  configuration  parame¬ 
ters  for  the  highest  Mach  number  used  in  the  set  of  NPSAERO  subcases  in 
the  Solution  Packet.  If  both  symmetric  and  antisymmetric  conditions  ex¬ 
ist  for  the  Mach  number,  both  sets  of  configuration  parameters  will  coex¬ 
ist  in  AIRFORCE.  (Output) 

A  aerodynamic  geometry  relation  output  only  for  geometry  checking.  The 
"grids"  defined  in  aerogecm  are  "connected"  to  2-node  (rods)  and  4-node 
(QtJADs)  elements  in  the  CAROGECM  in  such  a  way  as  to  emulate  the  struc¬ 
tural  model.  ICE  may  then  be  used  to  punch  an  equivalent  structural 
model  to  allow  graphical  presentation  of  the  steady  aero  model. 

A  aerodynamic  geometry  relation  output  only  for  geometry  checking.  The 
"grids"  defined  in  AEROGECM  are  "connected"  to  2-node  (rods)  and  4-node 
(quads)  elements  in  the  carogeom  in  such  a  way  as  to  emulate  tbs  struc¬ 
tural  model.  ICE  may  then  be  used  to  punch  an  equivalent  structural 
model  to  allow  graphical  presentation  of  the  steady  aero  model. 

A  relation  containing  the  rigid  forces  and  pressures  for  each  npsaero  sub¬ 
case’s  set  of  configuration  parameters  for  the  aerodynamic  elements 
whose  PRESSURE  output  was  requested  in  Solution  Control.  These  consti¬ 
tute  the  "trimmed”  state  of  the  configuration.  (Output) 
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Application  Calling  Sequence: 

None 

Method: 

The  STEADYNP  preface  module  perform  all  the  processing  for  nonplanar  STEADY  aerodynamics.  It  is 
driven  by  the  the  trim  data  present  in  the  bulk  data  packet  and  the  npsaerd  disciplines  in  the  case 
relation.  The  case  relation  provides  the  symmetries  while  the  TRIM  relation  provides  the  Mach 
numbers.  Only  if  npsaero  disciplines  are  in  case  is  any  processing  done  and  both  trim  and  aeros 
entries  must  be  found.  If  only  npsaero  cases  are  found  in  CASE,  the  nonponly  flag  is  set  to  true. 

Internally,  one  pass  is  made  over  the  steadynp  module  for  each  distinct  Mach  number  on  the  trims  in 
CASE.  On  erch  pass,  the  pasdfn  submodule  is  called  to  determine  the  set  of  all  Mach  numbers  and,  for 
each  Mach  number,  whether  symmetric,  antisymmetric  or  both  boundary  conditions  are  to  be  applied. 
Having  determined  all  unique  Mach  numbers,  the  passdf  then  determines  the  Mach  number  (in 
numerical  order  lowest  to  highest)  to  be  processed.  Amindkx  value  from  one  to  the  number  of  unique 
Mach  numbers  is  assigned  to  identify  the  pass.  If  the  chosen  Mach  number  is  the  last  one,  a  LOOP  flag 
is  set  to  false  to  tell  the  STEADYNP  that  no  more  passes  are  needed. 

On  the  first  pass,  the  steadynp  module  computes  the  nonplanar  steady  aerodynamic  geometry  in  calls 
to  gecm.  On  the  first  and  subsequent  passes,  it  then  processes  the  current  Mach  number  and  stores 
the  resultant  rigid  forces  due  to  unit  parameters  in  a  scratch  entity,  ^maximum  of  60  Mach  Index  values 
may  be  analyzed  in  a  single  ASTROS  job.  The  STABCF  relation  is  loaded  for  the  current  MINDEX  value 
with  the  symmetric  and  antisymmetric  stability  derivatives  in  the  same  order  that  the  rigid  force  matrix 
columns  are  loaded.  Hence,  the  STABCF  relation  points  to  the  corresponding  AIRFORCE  column. 

Once  all  the  airforce  matrices  for  each  Mach  number  index  are  computed,  the  npathm  submodule  is 
called  to  solve  the  "trim"  condition  for  each  subcase.  That  solution  involves  assembling  the  A  vector  from 
the  user’s  trim  entry  and  multiplying  the  rigid  unit  force  matrix  by  it.  If  any  PRESSURE  requests  are 
in  the  Solution  Control,  the  pressures  and  forces  on  the  appropriate  aerodynamic  boxes  are  loaded  to 
the  oagrdlod  relation.  Finally,  the  intermediate  rigid  force  matrices  are  deleted  except  for  the  last  one. 
Its  name  is  exchanged  for  that  of  AIRFORCE  so  that  it  is  available  to  the  MAPOL  sequence  for  user 
manipulation. 

Design  Requirements: 

1.  A  maximum  of  60  unique  Mach  numbers  may  be  analyzed  in  a  single  run. 

2.  Only  the  last  (highest)  Mach  number’s  rigid  unit  loads  matrix,  AIRFORCE,  is  saved  and  output  to  the 
MAPOL  sequence. 

Error  Conditions: 

1.  Errors  in  the  STEADY  aerodynamic  MODELS  or  TRIM  specifications  are  flagged. 
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Engineering  Application  Module:  TCEVAL 

Entry  Point:  TCEVAL 

Purpose: 

Tb  compute  the  current  values  of  thickness  constraints  for  this  optimization  iteration. 
MAPOL  Calling  Sequence: 

CALL  TCEVAL  (  NITER,  NDV,  MOVLIM,  WINDOW,  GLBDES,  LOCLVAR,  [PMINT] , 
[PMAXT] ,  TFIXED,  CONST  ); 


NITER 


MOVLIM 


WINDOW 


GLBDES 

LOCLVAR 


[PMINT] 


[PMAXT] 


TFIXED 


CONST 


Design  iteration  number  (Integer,  Input) 

The  number  of  design  variables  (Integer,  Input) 

Move  limit  to  apply  to  the  local  design  variables: 

t/MOVLIM  <  t  <  t  *  MOVLIM;  MOVLIM  >1.0 
(Real,  Input) 

The  window  around  the  zero  in  which  the  MOVLIM  bound  is  overridden  to 
allow  the  local  variable  to  change  sign.  If  window  *  0.0,  the  local  vari¬ 
able  may  not  change  sign.  If  WINDOW  is  nonzero,  the  half  width  of  a  band 
around  zero,  EPS  is  computed 

EPS  ■  WINDOW/ 100  *  MAX  {  ABS (1MIN) ,  ABS (TMAX)  ) 

If  the  local  variable  falls  within  the  band,  the  new  minimum  or  maximum 
for  the  current  iteration  is  changed  to  lie  on  the  other  side  of  zero  from 
the  local  variable.  The  bandwidth  EPS  is  a  percentage  of  the  larger  of 
TMAX  or  TMIN  where  WINDOW  specifies  the  percentage.  (Real,  Input) 

Relation  of  global  design  variables  (Input) 

Relation  containing  the  relationship  between  local  variables  and  global 
variables  in  the  design  problem  (Input) 

Matrix  entity  containing  the  minimum  thickness  constraint  sensitivities 
(Input) 

Matrix  entity  containing  the  maximum  thickness  constraint  sensitivities 
(Input) 

Relation  of  fixed  thickness  of  layer  (Input) 

Relation  of  constraint  values  (Output) 


iication  ( 


Method: 


The  module  determines  if  any  minimum  and  maximum  gauge  constraints  exist  in  the  problem.  These 
constraints  are  generated  by  ASTROS  if,  and  only  if,  shape  function  design  variable  linking  is  used.  If 
any  constraints  exist,  the  vector  of  design  variable  values  from  GLBDES  and  all  the  LOCLVAR  data  are 
brought  into  core.  The  next  step  is  to  determine  if  any  user  specified  move  limit  on  the  local  variables 
is  to  be  applied  to  the  minimum  thickness  constraints  (note  that  the  maximum  thickness  constraints 
are  always  computed  relative  to  their  gauge  limits  rather  than  to  a  move  limit). 
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If  move  limits  are  applied  (as  they  almost  always  are),  the  DCONTHK  or  DCOHTH2  data  are  also  brought 
into  core  to  identify  which  elements  minimum  gauge  constraints  are  always  to  be  retained  by  the 
constraint  deletion  algorithm  in  the  ACTCON  module.  The  minimum  gauge  constraints  are  then  computed 
by  performing  the  matrix  multiplication: 

{g>  =  1.0  -  {PMINT]T{v}  =  1.0  -  ~~ 

^mln 

The  L-OCLYAR  data  is  then  used  to  determine  to  which  element  each  "g"  applies.  If  the  constraint  value 
is  less  critical  (more  negative)  than  the  move  limit  value  of 

“  1.0  -  MOVLIM 

it  is  stored  on  the  CONST  relation  as  a  computed  constraint  only  if  it  appears  on  a  DCONTHK  cr 
DCONTH2entry  (in  which  case  it  will  end  up  as  an  active  constraint  from  actcon),  otherwise,  the 
constraint  is  ignored  for  this  design  iteration.  If  the  constraint  value  is  more  critical  than  the  move  limit 
value,  it  is  only  stored  on  CONST  if  it  is  on  a  DCONTHK  or  DCONTH2  entry  or  if  the  constraint  violates  a 
cutoff  value  set  to 

Wain  “0-1° 

Any  minimum  thickness  constraints  that  are  stored  on  CONST  that  do  not  appear  on  DCONTHK  or 
DCONTH2  entries  will  be  subject  to  the  normal  constraint  deletion  criteria.  The  maximum  gauge 
constraints  are  then  computed  by  performing  the  matrix  multiplication: 

(g)  «  [fmaxt]t{v}  +  (v}flxod  -  l.O 

The  LOCLVAR  data  is  then  used  to  determine  to  which  element  each  "g"  applies.  No  move  limits  are 
applied  to  these  constraints  and  they  are  stored  directly  to  the  CONST  relation  to  undergo  the  normal 
constraint  deletion  in  actcon. 

Design  Requirements: 

1.  This  module  should  be  the  first  module  called  in  the  optimization  phase  of  the  MAPOL  sequence. 

2.  The  move  limit  that  is  passed  into  this  routine  must  match  the  value  used  to  evaluate  the  constraints 
in  the  makdev  module.  If  not,  the  constraint  sensitivities  will  be  in  error  with  no  warning  given. 

Error  Conditions: 

1.  Alocal  variable  has  become  negative  due  to  insufficient  DCONTHK  or  DCQNTB2  entries  or  illegal  gauge 
constraints. 
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Engineering  Application  Module:  UNSTEADY 


Entry  Point:  UNSTDY 


Purpose: 

Unsteady  aeroelastic  analysis  preface. 


MAPQL  Calling  Sequence: 

CALL  UNSTEADY  (  GECKUA,  AECCMRU,  [AJJTL]  ,  [DlJK]  ,  [D2JK]  ,  [SKJ]  )  ; 


GECSfUA 


AECOSffiU 

[AJJTL] 

[D1JX] 

[D2JK] 

[3JK] 


A  relation  describing  the  aerodynamic  boxes  for  the  unSTEADY  aerody¬ 
namics  model.  The  location  of  the  box  centroid,  normal  and  pitch  moment 
axis  are  given.  It  is  used  in  splining  the  aerodynamics  to  the  structure 
and  to  map  responses  back  to  the  aerodynamic  boxes.  (Output) 

A  relation  describing  aerodynamic  components  for  the  unSTEADY  aerody¬ 
namics  model.  It  is  used  in  splining  the  aerodynamics  to  the  structural 
model.  (Output) 

A  matrix  containing  the  transposed  unsteady  Aic  matrices  for  each  Mach 
number,  reduced  frequency  and  symmetry  option  in  the  Bulk  Data 
MKAZROl  and  MKAER02  entries.  (Output) 

Real  part  of  the  substantial  derivative  matrix.  (Output) 

Imaginary  part  of  the  substantial  derivative  matrix.  (Output) 

Integration  matrix  to  take  pressures  to  forces.  (Output) 


Application  Calling  Saquence: 
None 


Method: 

The  unsteady  aerodynamics  preface  module  is  activated  under  the  following  conditions: 

1.  If  any  FLUTTER  cases  are  in  the  CASE  relation 

2.  If  any  blast  eases  are  in  the  CASE  relation 

3.  If  there  are  any  TRANSIENT  or  FREQUENCY  cases  that  invoke  the  GUST  option. 

After  checking  for  the  presence  of  the  proper  cases,  the  MKAEROl  and  MKAERQ2  data  are  read  from  the 
database  and  a  li3t  of  all  (s^mm,m,k}  sets  are  assembled.  The  first  record  of  the  UNMK  table  is  then 
written  containing  a  count  of  the  number  of  {m,k}  pairs  in  each  of  the  six  symmetry  classes.  The  second 
record  will  be  loaded  within  the  AH3  submodule  and  closed  on  return  to  UNSTEADY . 

Then  the  unsteady  aerodynamics  model  is  read  from  the  database  into  memory  for  the  APD  submodule. 
That  module  is  then  called  to  form  the  geometrical  description  of  the  unsteady  model.  The  ACPT,  the 
geomua  and  the  AECCMPU  entities  are  written  along  with  the  second  record  of  the  UNMK. 
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Once  the  geometry  data  are  complete,  the  amg  submodule  is  called  to  compute  the  ajjtl,  dijk,  D2 jk 
and  SKJ  matrices.  These  computations  are  done  for  all  the  {symm,m,k}  sets  in  the  bulk  data.  Each  ajjt 
matrix  is  appended  to  the  ajjtl  output  matrix.  The  dijk,  D2  JK  and  s  JK  matrices  will  have  two  separate 
matrices  stored  in  a  similar  fashion  if  and  only  if  both  subsonic  and  supersonic  Mach  numbers  appear 
in  the  UNMK  sets.  Once  these  computations  are  complete,  UNSTEAD?  returns  control  to  the  MAPOL 
sequence. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Engineering  Application  Module:  VANGO 
Entry  Point:  VANGO 


Purpose: 

Performs  redesign  by  optimality  criterion  methods  based  on  the  current  set  of  active  constraints  and 
constraint  senstivities. 


MAPOL  Calling  Sequence: 

CALL  VANGO  (  NITER,  NDV,  APPCNVRG,  MOVLIM,  CNVRGLXM,  CTL,  CTLMIN, 
NUtSOPTBC ,  GLBDES ,  CONST,  [AMAT],  DESHIST  ); 


NITER 

NDV 

APPCNVRG 

MOVLIM 


CNVRGLIM 


CTL 

CTIMIN 

NDfcKJPTBC 

GLBDES 

CONST 

AMAT 

DESHIST 


Current  iteration  number.  (Input,  Integer) 

Number  of  design  variables.  (Input,  Integer) 

Logical  flag  set  to  TRUE  if  the  approximate  problem  is  considered  con¬ 
verged  on  termination  of  the  module.  (Output,  Logical) 

The  move  limit  imposed  on  the  change  in  any  global  design  variable. 

VMIN  *  MAX  (VMIM ,  V/MDVLIM) 

VMAX  *  MIN  (VMAX ,  V*M3VLIM) 

Movlim  must  be  >  1 . 0,  if  not,  MOVLIM  is  set  to  10000 , 0  without  warn¬ 
ing.  (Input,  Real) 

The  user  supplied  tolerance  for  the  convergence  of  the  approximate  prob¬ 
lem.  The  objective  function  and  the  Euclidean  norm  of  the  delta  design 
variable  vector  must  be  less  than  cnvrglim  for  the  problem  to  be  consid¬ 
ered  converged.  (Real,  Input) 

Output  value  denoting  the  constraint  value  above  which  a  constraint  is 
considered  active.  (Real,  Output) 

Output  value  denoting  the  constraint  value  above  which  a  constraint  is 
considered  violated.  (Real,  Output) 

The  number  of  optimization  boundary  conditions.  (Integer,  Input) 

The  relation  of  global  design  variables.  (Input) 

The  relation  of  design  constraints.  (Input) 

The  matrix  of  active  constraint  gradients.  (Input) 

The  relation  of  design  variable  history  data.  (Output) 


Application  Calling  Sequence: 
None 


Method: 

First  the  GLBDES  relation  is  read  to  obtain  global  design  variable  data  and  the  objective  function 
gradients.  Then  the  design  variable  values,  lower  and  upper  bounds  and  scaling  information  is  stored 
into  local  arrays  accounting  for  the  move  limits.  The  move  limit  is  a  user  parameter  that  is  controlled 
through  the  Solution  Control  OFT IMIZ2/0CMDV1-TM  value.  The  default  value  is  10000 . 0  which  implies 


237 


that  move  limits  will  not  be  imposed.  The  VANGO  module  does  not  require  move  limits  in  the  same  way 
that  the  design  module  does.  The  defaults  are  recommended. 

The  constraint  gradients  are  then  read  into  memory  and  scaled  as  appropriate  for  the  design  variable 
scaling.  Then  the  const  data  are  read  and  reordered  to  ensure  that  the  active  constraint  values  line  up 
in  memory  with  their  respective  constraint  gradients.  Then,  the  constraint  values  are  modified  by  adding 
1.0  to  the  constraint  value  since  the  FUNOPT  Optimality  Resizing  software  requires  that  the  constraint 
inequality  limit  be  nonzero  while  ASTROS  uses  zero  exclusively. 

Then  a  call  is  made  to  vanovr  to  get  the  user  overrides  to  the  FUNOPT  parameters  from  the  ocpakm 
bulk  data  entries.  Then,  the  saved  values  of  FUNOPT-controlled  parameters  are  retrieved  from  storage. 
On  the  first  iteration  of  OC  methods,  funopt  will  initialize  these  parameters.  They  are: 


ISTAT  from  word  2  of  the  IPBM  array 
NCSC  from  word  4  of  the  I  PPM  array 
iter  from  word  8  of  the  IPBM  array 
nrtain  from  word  10  of  the  IPBM  array 
IGRDST  from  word  11  of  the  IPBM  array 
objrsz  from  word  14  of  the  RPRM  array 

Then  the  loop  over  FUNOPT  is  begun.  Only  if  the  OCAPPROX  option  is  selected  will  multiple  passes  through 
funopt  t..Ke  place.  In  the  default  behavior,  the  constraints,  constraint  gradients  and  design  variable 
are  passed  to  funopt  and  the  new  design  variables  are  output. 

After  "convergence"  has  been  reached,  the  current  values  of  the  funopt  parameters  are  saved  to  the 
database  for  retrieval  on  subsequent  calls.  The  new  design  variables  are  written  to  GLBDES  and  the 
deshist  data  are  computed.  Finally,  the  convergence  criteria  for  approximate  problem  convergence  are 
checked  through  the  use  of  the  ACNVRG  submodule. 

Design  Requirements: 

1,  The  debug  packet  input  ocapprox  is  used  to  choose  whether  VANGO  will  use  the  approximate  problem 
equations  to  predict  a  new  set  of  constraint  values  and  constraint  gradients  following  a  design  variable 
move.  A  value  >  0  allows  vango  to  use  the  linear  gradients  to  predict  new  constraint  values.  A  value  of 
0  forces  a  complete  new  analysis  after  the  new  variables  have  been  computed.  (The  use  of  the 
approximate  problem  is  is  an  experimental  feature  and  should  not  be  used). 

2.  The  debug  packet  input  ocinv  is  used  to  choose  whether  VANGO  will  use  inverse  design  variables  or 
direct  design  variables  in  the  solution  of  the  problem.  Avalue  greater  than  zero  allows  vango  to  use  the 
inverse  design  variable  approximations.  (This  is  an  experimental  feature  and  should  not  be  used). 

Error  Conditions: 

None 
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Engineering  Application  Module:  YSMERGE 

Entry  Point:  YSMERG 

Purpose: 

Tb  provide  a  special  purpose  merge  utility  for  merging  Y  3- like  vectors  (vectors  of  enforced  displacements) 
into  matrices  for  data  recover}’. 

MAPOL  Calling  Sequence: 

CALL  YSMERGE  (  [ON] , 

[UN] 

[YS (BC) ] 

[UF] 

[PNSF (BC) ] 

DYNFLG 

Application  Calling  Sequence: 

None 
Method: 

The  ysmerge  engineering  utility  module  is  a  general  utility  to  merge  a  column  vector,  YS,  (or  a  null 
column)  that  represents  a  partition  of  the  desired  output  matrix  with  the  other  partition,  UF,  based  on 
an  input  partitioning  vector.  The  column  dimension  of  UF  is  used  to  determine  the  number  of  times  YS 
is  to  be  duplicated  in  the  merge  operation.  The  result  is  loaded  into  the  UN  matrix.  As  a  special  option, 
the  dynflg  input  is  used  to  direct  the  module  to  assume  that  the  UF  and  UN  matrices  have,  or  are  to 
have,  the  form  of  a  dynamic  response  "displacement”  matrix.  These  matrices  have  three  columns  for 
each  time/frequency  step: 

(1)  Displacement 

(2)  Velocity 

(3)  Acceleration 

When  dynflg  is  nonzero,  the  YS  matrix  is  merged  with  the  first  column  (displacements)  of  each  triplet 
with  null  partitions  used  for  the  corresponding  velocities  and  accelerations. 

Design  Requirements: 

1.  The  YS  matrix  entity,  if  it  is  included  in  the  calling  sequence,  must  be  null  (no  columns)  or  be  a  column 
vector.  If  the  matrix  is  null,  the  routine  acts  as  though  it  were  not  included  in  the  calling  sequence. 

Error  Conditions: 

None 


[YS (BC) ] ,  [UF] ,  [PNSF(BC) ] ,  DYNFLG  ) ; 

Matrix  containing  the  nodal  response  quantities  for  the  independent  de¬ 
grees  of  freedom  (Output) 

Optional  matrix  containing  the  vector  of  enforced  displacements  on  the 
single-point  constre-nt  degrees  of  freedom.  If  the  YS  argument  is  omitted, 
null  vectors  are  merged.  (Input) 

The  matrix  of  free  nodal  response  quantities  to  be  merged  with  the  YS  vec¬ 
tor 

The  partitioning  vector  splitting  the  independent  degrees  of  freedom  into 
the  free  and  the  single  point  constraint  degrees  of  freedom  (Input) 

Dynamic  matrix  form  flag:  if  dynflg  is  nonzero,  the  matrix  UF  is  as¬ 
sumed  to  have  the  form  of  a  dynamic  response  matrix:  three  columns  per 
subcase;  (1)  displacement,  (2)  velocity  and  (3)  acceleration  (Integer,  Input) 
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Large  software  systems  such  as  ASTROS  require  that  similar  operations  be  performed  in  many 
code  segments.  To  reduce  the  maintenance  effort  and  to  ease  the  programming  task,  a  set  of  commonly 
used  application  utilities  were  identified  and  used  whenever  the  application  required  those  tasks  to  be 
performed.  This  section  is  devoted  to  the  documentation  of  the  set  of  application  utilities  in  ASTROS.  The 
suite  of  utilities  in  ASTROS  includes  small  (performed  entirely  in  memory)  matrix  operations  like  linear 
equation  solvers,  matrix  multiplication  and  others.  Another  suite  of  utilities  have  been  written  to  sort 
tables  or  columns  of  data  on  real,  integer  and  character  values  in  the  table.  Other  utilities  search  lists  of 
data  stored  in  memory  for  particular  key  values,  initialize  arrays,  operate  on  matrix  entities  and  perform 
other  disparate  tasks  of  a  general  nature.  The  ASTROS  user  who  intends  to  write  application  programs 
to  be  used  within  the  ASTROS  environment  is  strongly  urged  to  study  the  suite  of  utilities  documented  in 
this  section.  ASTROS  software  designed  to  make  use  of  the  suite  of  application  utilities  can  be  much 
simpler  to  write,  debug  and  maintain  since  these  well-tested  utilities  can  be  substituted  for  code  that 
would  otherwise  require  programming  effort. 

The  following  e-,bsections  document  the  interface  to  the  application  utilities  in  two  formats;  using 
the  executive  system  (MAPOL)  and  using  the  FORTRAN  calling  sequence.  In  most  cases,  there  is  no 
MAPOL  language  interface  since  these  utilities  are  useful  only  within  an  application  module.  In  other 
cases,  however,  the  utility  has  been  identified  as  a  feature  accessible  through  the  executive.  Finally,  a 
small  number  of  these  application  utilities  are  intended  for  access  only  by  the  executive  system.  This 
family  of  utilities  is  always  associated  with  obtaining  formatted  output  of  data  stored  on  the  database. 
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Application  Utility  Module:  APPEND 

Entry  Point:  APPEND 

Purpose: 

This  routine  adds  all  the  columns  of  one  input  matrix  to  the  end  of  another. 

MAPOL  Calling  Sequence: 

CALL  APPEND  (  MATOUT,  MATIN  ) ; 

Application  Calling  Sequence: 

CALL  APPEND  (  MATOUT,  MATIN,  IKOR  ) 

MATOUT  The  name  of  the  output  matrix  to  which  the  columns  are  added 

(Character,  Output) 

matin  The  name  of  the  input  matrix  from  which  the  extra  columns  are  extracted 

(Character,  Input) 

IKOR  Open  core  base  address  for  local  dynamic  memory  allocation 

(Integer,  Input) 

Method: 

Matrix  MATOUT  is  first  initialized.  Error  checks  are  made  to  see  if  the  matrices  are  conformable  for  the 
append  operation.  The  columns  of  MATIN  are  then  appended  to  the  MATOUT  matrix  with  special 
provisions  given  to  handle  null  columns  in  KATIN. 

Design  Requirements: 

None 

Error  Conditions: 

1.  matout  has  not  been  created  first  (append  does  an  MXINIT,  but  the  entity  must  already  exist  as  a 
matrix). 

2.  MATOUT  and  matin  have  different  types  (precision/real  or  complex). 

3.  matout  and  matin  have  a  different  number  of  rows. 
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Application  Utility  Module:  DAXB 

Entry  Point:  DAXB 

Purpose: 

This  routine  takes  the  double-pi  vision  cross  product  of  vectors  in  a  three-dimensional  space. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DAXB  (  A,  B,  C  ) 

A  is  a  vector  (3x1)  (Double,  Input) 

B  is  a  vector  (3x1)  (Double,  Input) 

c  On  output,  cross  product  A  X  B  (Double,  Output) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  GMMA.TC 

Entry  Point:  GMMATC 

Purpose: 

Perform  the  in-core  complex  matrix  multiplications: 

[A][B]  «  [C] 

[A]  [B]t  -  [C] 

[A]t[B]  -  [C] 

[A]T[B]T  =  [C] 

MAPOL  Calling  Sequence: 


Application  Calling  Sequence: 

CALL  GMMATC  (  A,  lUOMA,  ICOLA,  MTA,  B,  IROWB,  ICOLB,  NTB,  C  ) 

a  Matrix  of  IROWA  rows  and  ICOLA  columns  stored  in  row  order  in  a  linear 

array 

B  Matrix  of  IROWB  rows  and  ICOLB  columns  stored  in  row  order  in  a  linear 

array 


MTA, NTB  Transpose  flags 

«  0  if  no  transpose 
«  1  if  transpose 

C  On  output,  the  result  of  the  matrix  multiplication 

Method: 

The  GMMATC  routine  assumes  that  sufficient  storage  space  is  available  in  core  to  perform  the  multipli¬ 
cation.  Hie  matrices  are  checked  to  ensure  that  they  are  of  proper  dimensions  to  be  multiplied.  Complex 
single-precision  is  used  throughout  the  routine. 

Design  Requirements: 


Error  Conditions: 
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Application  Utility  Module:  GMMATD 
Entry  Point:  GMMATD 


Purpose: 

Perform  the  in-core  double-precision  matrix  multiplications: 

tA][B]  =  [C] 

CA]  [B]t  =  [C] 

[A]t[B]  -  [C] 

[A]T[B]T  -  [C] 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  GfrMATD  (  A,  IROWA,  ICOLA,  MTA,  B,  IROWB,  ICOLB,  KTB,  C  ) 

A  Matrix  of  IROWA  rows  and  ICOLA  columns  stored  in  row  order  in  a 

array 

B  Matrix  of  IROWB  rows  and  icolb  columns  stored  in  row  order  in  a 

array 

MTA ,  ntb  Transpose  flags 

=  0  if  no  transpose 
*  1  if  transpose 

c  On  output,  the  result  of  the  matrix  multiplication 

Method: 

The  qmatd  routine  assumes  that  sufficient  storage  space  is  available  in  core  to  perform  the  multipli¬ 
cation.  The  matrices  are  checked  to  ensure  that  they  are  of  proper  dimensions  to  be  multiplied.  Double 
precision  is  used  throughout  the  routine. 

Design  Requirements: 

None 

Error  Conditions: 

None 


linear 

linear 
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Application  Utility  Module:  Q44A.TS 

Entry  Point:  GMMA.TS 

Purpose: 

Perform  the  in-core  single-precision  matrix  multiplications: 

[AJ[B]  *  [C] 

[A]  [B]t  *  [C] 

[A]T[B]  -  [C] 

[A]T[B3T  «  [C] 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  OMMATS  (  A,  IROWA,  ICOIA,  MTA,  B,  IROWB,  ICOLB,  NTB,  C  ) 

A  Matrix  of  irowa  rows  and  ICOLA  columns  stored  in  row  order  in  a  linear 

array 

B  Matrix  of  IROWB  rows  and  ICOLB  columns  stored  in  row  order  in  a  linear 

array 

KTA,NTB  Transpose  flags 

=  0  if  no  transpose 
=  1  if  transpose 

C  On  output,  the  result  of  the  matrix  multiplication 

Method: 

The  GM4ATS  routine  assumes  that  sufficient  storage  space  is  available  in  core  to  perform  the  multipli¬ 
cation.  The  matrices  are  checked  to  ensure  that  they  are  of  proper  dimensions  to  be  multiplied.  Single 
precision  is  used  throughout  the  routine. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module: 


INVERC 


Entry  Point:  INVERC 
Purpose: 

Single  precision  complex  in-core  matrix  inversion  and  linear  equation  solver.  Finds  solution  to  the  matrix 
equation: 


[AHXf  -  {B} 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  INVERC  «  NDIM,  A,  N,  B,  M,  DETERM,  ISING,  INDEX  ) 

Actual  dimension  size  of  square  matrix  A  in  calling  routine: 

A  (NDIM, NDIM)  (Integer,  Input) 

Square  matrix  to  be  inverted.  On  output,  contains  of  inverse  of  A 
(Complex,  Input) 

Size  of  upper  left  portion  being  inverted.  (Integer,  Input) 

Column  of  constants  (optional  input  of  minimum  size:  B  (NDIM,  1)  ).  On 
output,  contains  the  solution  V6ctor(s)  of  the  linear  equations 
(Complex,  Input) 

Number  of  columns  of  B  (Integer,  Input) 

Determinant  of  A  if  nonsingular  (Complex,  Output) 

Error  flag 

=  1  if  A  nonsingular 
*  2  if  A  singular 
(Integer,  Input  and  Output) 

Working  storage  (N,3)  (Complex,  Input) 


If  on  input,  the  value  of  ISING  is  less  than  zero,  the  determinant  of  the  A  matrix  is  not  calculated.  The 
value  of  determ  on  return  will  be  zero.  The  matrix  inversion  routine  uses  the  Gauss-Jordian  method 
with  complete  row-column  interchange.  Sufficient  core  storage  must  be  set  aside  in  INDEX  to  complete 
the  inversion. 

Error  Conditions: 

None 


NDIM 


N 

B 

M 

DETERM 

ISING 


INDEX 


Method: 
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Application  Utility  Module:  INVERD 
Entry  Point:  INVERD 


Purpose: 

Double  precision  in-core  matrix  inversion  and  linear  equation  solver.  Finds  solution  to  the  matrix 
equation: 

[A] {X}  -  {B} 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  INVERD  (  NDIM,  A,  N,  B,  M,  DETERM,  ISING,  INDEX  ) 


NDIM 

Actual  dimension  size  of  square  matrix  Ain  calling  routine: 

A  (NDIM, NDIM)  (Integer,  Input) 

A 

Square  matrix  to  be  inverted.  On  output,  contains  of  inverse  of  A 
(Double,  Input) 

N 

Size  of  upper  left  portion  being  inverted.  (Integer,  Input) 

B 

Column  of  constants  (optional  input  of  minimum  size:  B  (NDIM,  1)  ).  On 
output,  contains  the  solution  vectors)  of  the  linear  equations 
(Double,  Input) 

M 

Number  of  columns  of  B  (Integer,  Input) 

DETERM 

Determinant  of  A  if  nonsingular  (Double,  Output) 

ISING 

Error  flag 

=  1  if  A  nonsingular 
=  2  if  A  singular 
(Integer,  Input  and  Output) 

INDEX 

Working  storage  (N,3)  (Double,  Input) 

Method: 

If  on  input,  the  value  of  ISING  is  less  than  zero,  the  determinant  of  the  A  matrix  is  not  calculated.  The 
value  of  determ  on  return  will  be  zero.  The  matrix  inversion  routine  uses  the  Gauss-Jordian  method 
with  complete  row-column  interchange.  Sufficient  core  storage  must  be  set  aside  in  INDEX  to  complete 
the  inversion. 

Error  Conditions: 

None 
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Application  Utility  Module:  INVERS 
Entry  Point:  INVERS 


Purpose: 

Single  precision  in-core  matrix  inversion  and  linear  equation  solver.  Finds  solution  to  the  matrix 
equation: 

CA]{X)  =  {B} 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  INVERS  (  NDIM,  A,  N,  B,  M,  DETERM,  ISING,  INDEX  ) 

HDIM  Actual  dimension  size  of  square  matrix  Ain  calling  routine:  A  (NDIM, NDIM) 

(Integer,  Input) 

A  Square  matrix  to  be  inverted.  On  output,  contains  of  inverse  of  A 

(Real,  Input) 

N  Size  of  upper  left  portion  being  inverted.  (Integer,  Input) 

B  Column  of  constants  (optional  input  of  minimum  size:  B  (NDIM,  1)  ).  On 

output,  contains  the  solution  vectors)  of  the  linear  equations  (Real,  Input) 

M  Number  of  columns  of  B  (Integer,  Input) 

DETERM  Determinant  of  A  if  nonsingular  (Real,  Output) 

ISING  Error  flag 

=  1  if  A  nonsingular 
*  2  if  A  singular 
(Integer,  Input  and  Output) 

index  Working  storage  (N,3)  (Real,  Input) 

Method: 

If  on  input,  the  value  of  ISING  is  less  than  zero,  the  determinant  of  the  A  matrix  is  not  calculated.  The 
value  of  DETERM  on  return  will  be  zero.  The  matrix  inversion  routine  uses  the  Gauss-Jordian  method 
with  complete  row-column  interchange.  Sufficient  core  storage  must  be  set  aside  in  INDEX  to  complete 
the  inversion. 

Error  Conditions: 

None 
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Application  Utility  Module:  MSGDMP 

Entry  Point:  MSGDMP 

Purpose: 


Retrieves  messages  queued  by  the  otmwrt  module  and  writes  them  to  the  system  output  file. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MSGDMP 

Method: 

The  Msgdmp  routine  reads  the  queued  messages  written  by  OTMHRT  from  the  queue  file  and  writes  them 
onto  the  system  output  file.  The  queue  file  is  then  reset  to  accept  the  next  set  of  messages.  The  intention 
is  thatMSGDMP  will  be  called  after  each  module’s  execution  to  allow  easy  determination  of  the  last  module 
executed,  should  the  execution  terminate. 

Error  Conditions: 

None 
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Application  Utility  Module:  POLCOD 

Entry  Point:  POLCOD 

Purpose: 

This  routine  computes  double-precision  polynomial  fit  coefficients. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  POLCOD  (  X,  X ,  N,  S,  COF  ) 

X  The  vector  of  scalar  variables  of  length  N  (Input,  Double  Precision) 

X  The  vector  of  terms  such  that 

[X(l>]  -  [V]  at  X(l) 

(Input,  Double  Precision) 

N  The  rank  of  vectors  X  and  X  (Input,  Integer) 

s  The  scratch  array  of  length  N  to  store  the  master  polynomial  coefficients 

(Input,  Double  Precision) 

cof  The  vector  of  coefficients  such  that 

[X(Z>]  *  [COF(l) ]  +  Z [COF (2) ]  +  Z**2 [COF (3) ] 

(Output,  Double  Precision) 

Method: 

This  routine  computes  polynomial  fit  coefficients  from  solution  of  Vandermonde  matrix  equations.  It  is 
taken  from  "Numerical  Recipes,"  Section  3.5,  routine  POLCOD. 

Design  Requirements: 

1.  Use  FOLEVD  to  evaluate  the  polynomial  values  based  on  the  computed  coefficients. 

2.  Use  polsld  to  evaluate  the  polynomial  derivative  values  based  on  the  computed  coefficients. 
Error  Conditions: 

None 
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Application  Utility  Module:  POLCOS 

Entry  Point:  POLCOS 

Purpose: 

This  routine  computes  single-precision  polynomial  fit  coefficients. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALI  POLCOS  (  X,  Y,  N,  S,  COF  ) 

X  The  vector  of  scalar  variables  of  length  H  (Input,  Real) 

Y  The  vector  of  terms  such  that 

[y<i>]  -  [y]  at  x(i) 

[y (2) ]  =  [y]  at  x<2) 

(Input,  Real) 

N  The  rank  of  vectors  X  and  y  (Input,  Integer) 

S  The  scratch  array  of  length  N  to  store  the  master  polynomial  coefficients 

(Input,  Real) 

cof  The  vector  of  coefficients  such  that 

[y(Z)l  «=  [COF  (1)  ]  +  Z  [COF  (2)  ]  +  Z**2[COF(3)] 

(Output,  Real) 

Method: 

This  routine  computes  polynomial  fit  coefficients  from  solution  of  Vandermonde  matrix  equations.  It  is 
taken  from  "Numerical  Recipes,"  Section  3.5,  routine  POLCOE. 

Design  Requirements: 

1.  Use  polevs  to  evaluate  the  polynomial  values  based  on  the  computed  coefficients. 

2.  Use  polsls  to  evaluate  the  polynomial  derivative  values  based  on  the  computed  coefficients. 
Error  Conditions: 

None 
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Application  Utility  Module:  POLEVD 

Entry  Point:  POLEVD 

Purpose: 

This  routine  performs  double-precision  polynomial  evaluation  from  fit  coefficients. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  POLEVD  (  COF,  N,  X,  Y  ) 

cof  Th8  vector  of  coefficients  such  that 

[Y  (Z) ]  -  [COF (1) ]  +  Z [COF (2) ]  +  Z**2 [COF (3) ] 

(Input,  Double  Precision) 

n  The  rank  of  vectors  x  and  Y  (Input,  Integer) 

X  The  scalar  value  at  which  polynomial  is  evaluated 

(Input,  Double  Precision) 

Y  The  function  value  at  X  (Output,  Double  Precision) 

Method: 

This  routine  performs  double-precision  polynomial  evaluation  from  fit  coefficients  from  solution  of 
Vandermonde  matrix  equations.  It  is  taken  from  "Numerical  Recipes,"  Section  3.5,  routine  POLCOE. 

Design  Requirements: 

1.  Use  polcod  to  evaluate  the  fit  coefficients. 

2.  Use  polsld  to  evaluate  the  polynomial  derivative  values  based  on  the  computed  coefficients. 
Error  Conditions: 

None 
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Application  Utility  Module:  POLEVS 

Entry  Point:  POLEVS 

Purpose: 

This  routine  performs  single-precision  polynomial  evaluation  from  fit  coefficients. 

MAFOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  POLEVS  {  COS',  N,  X,  ¥  ) 

COS'  The  vector  of  coefficients  such  that 

[Y(Z)]  =  [COF(l) ]  +  Z [COF (2) ]  +  Z**2[COF(3)] 

(Input,  Real) 

U  The  rank  of  vectors  x  and  Y  (Input,  Integer) 

X  The  scalar  value  at  which  polynomial  is  evaluated  (Input,  Real) 

Y  The  function  value  at  X  (Output,  Real) 

Method: 

This  routine  performs  single-precision  polynomial  evaluation  from  fit  coefficients  from  solution  of 
Vandermonde  matrix  equations.  It  is  taken  from  "Numerical  Recipes,”  Section  3.6,  routine  POLCOE. 

Design  Requirements: 

1.  Use  polcos  to  evaluate  the  fit  coefficients. 

2.  Use  POLSLS  to  evaluate  the  polynomial  derivative  values  based  on  the  computed  coefficients. 
Error  Conditions: 

None 
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Application  Utility  Module:  POLSLD 

Entry  Point:  POLSLD 

Purpose: 

This  routine  performs  double-precision  polynomial  derivative  evaluation  from  fit  coefficients. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  POLSLD  (  COF,  N,  X,  Y  ) 

cof  The  vector  of  coefficients  such  that 

[Y  (Z) ]  «  [COF (1)3  +  Z [COF (2)]  +  Z**2[COF(3)3 
(Input,  Double  Precision) 

N  The  rank  of  vectors  X  and  Y  (Input,  Integer) 

x  The  scalar  value  at  which  polynomial  is  evaluated 

(Input,  Double  Precision) 

Y  The  slope  of  function  at  X  (Output,  Double  Precision) 

Method: 

This  routine  performs  double-precision  polynomial  derivative  evaluation  from  fit  coefficients  from 
solution  of  Vandermonde  matrix  equations.  It  is  taken  from  "Numerical  Recipes,"  Section  2.5,  routine 
POLCOE. 

Design  Requirements: 

1.  Use  polcod  to  evaluate  the  fit  coefficients. 

2.  Use  polevd  to  evaluate  the  polynomial  values  based  on  the  computed  coefficients. 

Error  Conditions: 

None 
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Application  Utility  Module:  POLSLS 

Entry  Point:  POLSLS 

Purpose: 

This  routine  performs  single-precision  polynomial  derivative  evaluation  from  fit  coefficients. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  POLSLS  (  COF,  N,  X,  X  ) 

COF  The  vector  of  coefficients  such  that 

[X(Z)J  ■  [COF (1) ]  +  Z [COF (2) ]  +  Z**2[COF{3>] 

(Input,  Heal) 

N  The  rank  of  vectors  x  and  x  (Input,  Integer) 

x  The  scalar  value  at  which  polynomial  is  evaluated  (Input,  Real) 

X  The  slope  of  function  at  X  (Output,  Real) 

Method: 

This  routine  performs  single-precision  polynomial  derivative  evaluation  from  fit  coefficients  from 
solution  of  Vandermonde  matrix  equations.  It  is  taken  from  "Numerical  Recipes,"  Section  3.5,  routine 
POLCOE. 

Design  Requirements: 

1.  Use  polcod  to  evaluate  the  fit  coefficients. 

2.  Use  polevd  to  evaluate  the  polynomial  values  based  on  the  computed  coefficients. 

Error  Conditions: 

None 
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Application  Utility  Module:  PS 

Entry  Point:  PS 

Purpose: 

Character  function  returns  the  character  string  as  the  matrix  precision  needed  for  MXINIT,  memory 
management  and  others  based  on  the  machine  precision 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

PS  (  TYPFLG  ) 

TYPFLG  Character  string,  either  "R"  or  "C"  for  real  or  complex  (Character,  Input) 

Method: 

PS  returns  character  string  RDP  on  double-precision  machines  or  RSP  on  single-precision  machines  for 
input  TYPFLG  of  R,  in  other  words  PS  { '  R' )  returns  either  RSP  or  RDP.  The  complex  equivalent  CDP  or 
csp  is  returned  if  TYPFLG  is  C. 

Design  Requirements: 

None 

Error  Conditions: 

1.  If  typflg  in  ps  is  neither  "r"  nor  "c",  PS  will  return  blank. 
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Application  Utility  Module:  RDDMAT 

Entry  Point:  RDDMAT 

Purpose: 

Reads  a  double-precision  matrix  entity  into  memory. 

MAPQL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  RDDMAT  (  MATN&M,  NROW,  NCOL,  BLKN,  GRPN,  PNTR,  DKOR  ) 


MATNAM 

NROW 

NCOL 

BLKN 

GRPN 

PNTR 

DKOR 


Input  Matrix  database  entity  (Character,  Input) 

The  number  of  rows  in  the  matrix  (Integer,  Output) 

The  number  of  columns  in  the  matrix  (Integer,  Output) 

The  name  of  the  _pen  core  block  to  which  the  data  are  written 
(Character,  Input) 

The  narn'j  of  the  open  core  group  to  which  the  data  are  written 
(Character,  Input) 

The  pointer  to  DKOR  where  the  matrix  data  begin.  (Integer,  Output) 
The  double-precision  open  core  base  address.  (Double,  Input) 


Method: 


The  matrix  is  opened,  its  size  determined  and  a  memory  block  with  group  name  GRPN  and  block  name 
BLKN  is  allocated  to  hold  the  matrix  data.  The  matrix  is  then  read  into  core  with  special  provisions  being 
taken  to  handle  the  case  of  null  columns.  The  matrix  is  then  closed.  The  calling  routine  is  responsible 
for  freeing  the  memory  block. 

Design  Requirements: 

1.  The  matrix  must  be  closed  on  calling  this  routine. 

Error  Conditions: 

1.  Insufficient  open  core  memory  will  cause  ASTROS  termination. 
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Application  Utility  Module:  RDDM&.7 


Entry  Point:  RDDMAT 
Purpose: 

n  .»  m  gh  ■  i  «  >-»m 

Reads  a  double-precision  matrix  entity  into  memory. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  RDDMAT  {  MATNAM,  NROW,  NCOL,  BLKN,  GRPN,  PNTR,  DKOR 


MATKAM 

NRON 

NCOL 

BLKN 

GRPN 

PNTR 

DKOR 


Input  Matrix  database  entity  (Character,  Input) 

The  number  of  rows  in  the  matrix  (Integer,  Output) 

The  number  of  columns  in  the  matrix  (Integer,  Output) 

The  name  of  the  open  core  block  to  which  the  data  are  written 
(Character,  Input) 

The  name  of  the  open  core  group  to  which  the  data  are  written 
(Character,  Input) 

The  pointer  to  DKOR  where  the  matrix  data  begin.  (Integer,  Output) 
The  double-precision  open  core  base  address.  (Double,  Input) 


Method: 

The  matrix  is  opened,  its  size  determined  and  a  memory  block  with  group  name  GRPN  and  block  name 
BLKN  is  allocated  to  hold  the  matrix  data.  The  matrix  is  then  read  into  core  with  special  provisions  feeing 
taken  to  handle  the  case  of  null  columns.  The  matrix  is  then  closed.  The  calling  routine  is  responsible 
for  freeing  the  memory  block. 

Design  Requirements: 

1.  The  matrix  must  be  closed  on  calling  this  routine. 

Error  Conditions: 

1.  Insufficient  open  core  memory  will  cause  ASTROS  termination. 
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Application  Utility  Module:  RDSMAT 

Entry  Point:  RDSMAT 

Purpose: 

Reads  a  double-precision  matrix  entity  into  memory. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  RDSMAT  (  MAT NAM,  BROW,  NCOL,  BLKN,  GRFN,  FNTR,  RKOR  ) 

MATNAM  Input  Matrix  database  entity  (Character,  Input) 

krcw  The  number  of  rows  in  the  matrix  (Integer,  Output) 

ncol  The  number  of  columns  in  the  matrix  (Integer,  Output) 

blkn  The  name  of  the  open  core  block  to  which  the  data  are  written 

(Character,  Input) 

GRFN  The  name  of  the  open  core  group  to  which  the  data  are  written 

(Character,  Input) 

pntr  The  pointer  to  DKOR  where  the  matrix  data  begin.  (Integer,  Output) 

RKOR  The  single-precision  open  core  base  address.  (Real,  Input) 

Method: 

The  matrix  is  opened,  its  size  determined  and  a  memory  block  with  group  name  GRFN  and  block  name 
BLKN  is  allocated  to  hold  the  matrix  data.  The  matrix  is  then  read  into  core  with  special  provisions  being 
taken  to  handle  the  case  of  null  columns.  The  matrix  is  then  closed.  The  calling  routine  is  responsible 
for  freeing  the  memory  block. 

Design  Requirements: 

1.  The  matrix  must  be  closed  on  calling  this  routine. 

Error  Conditions: 

1.  Insufficient  open  core  memory  will  cause  ASTROS  termination. 
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Application  Utility  Module:  SAXB 
Entry  Point:  SAXB 


Purpose: 

This  routine  takes  the  double-precision  cross  product  of  vectors  in  a  three-dimensional  space. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  SAXB  (  A,  B,  C  ) 

A  is  a  vector  (3x1)  (Real,  Input) 

B  is  a  vector  (3x1;  (Real,  Input) 

C  On  output,  cross  product  A  X  B  (Real,  Output) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  USETPRT 

Entry  Point:  USETPR 

Purpose: 

Tb  print  the  structural  set  definition  table  for  each  boundary  condition  contained  in  the  USET  entity. 

MAPGL  Calling  Sequence: 

CALL  USETPRT  (  USET(BC)  ,  BGPDT(BC)  ) 

uset  The  name  of  the  current  boundary  condition’s  US3T  entity. 

( Character,  Input ) 

bgfdt  The  name  of  the  current  boundary  condition’s  BGPDT  entity. 

( Character,  Input ) 

Application  Calling  Sequence: 

None 

Method: 

The  uset  entity  is  opened  to  determine  which  boundary  condition  is  to  be  processed.  The  CASE  relation 
is  opened  and  the  appropriate  title,  SUBTITLE  and  LABEL  information  are  obtained. 

The  INTID,  EXTID  and  flag  attributes  o"  the  BGPDT  are  brought  into  core  and  sorted  on  internal  id. 
The  USET  record  for  the  current  boundary  condition  is  also  brought  into  an  open  core  memory  block. 
Each  tuple  of  the  BGPDT  is  processed;  each  point  in  the  structural  set  has  its  corresponding  USET  bit 
mask  decoded  to  determine  to  which  structural  sets  the  degree  of  freedom  belongs.  A  running  count  in 
each  dependent  and  independent  structural  set  is  maintained  and  echoed. 

Error  Conditions: 

Nor.) 
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Application  Utility  Module:  UTCOPY 

Entry  Point:  UTCOPY 

Purpose: 

lb  copy  a  specified  number  of  contiguous  single-precision  words  from  one  location  to  another. 
Application  Calling  Sequence: 

CALL  UTCOPY  (  DEST,  SOURCE,  NWORD  ) 
dest  Array  tc  be  copied  to 

source  Array  to  be  copied  from 

nword  Number  of  single-precision  words  to  be  copied 

Method: 

The  source  and  destination  arrays  are  operated  on  as  integer  arrays  inside  the  UTCOPY  routine.  If 
double-precision  data  are  to  be  copied,  the  NWORD  argument  must  be  adjusted  accordingly. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTCSRT 

Entry  Point:  UTCSRT 

Purpose: 

lb  sort  a  table  of  numbers  on  a  four  or  eight  character  hollerith  column  of  the  table 
MAPOL  Calling  Sequence: 

None 


Application  Calling  Sequence: 

CALI.  UTCSRT  <  ISORT,  I THROW,  BOTLIM,  TOPLIM,  KEYPOS,  TOTLEN,  KEYLEN  ) 


ISORT 

Array  to  be  sorted  (Any,  Input) 

I THROW 

An  array  of  length  TOTLEN  single-precision  words  used  to  store  a  table 
row  (Any,  Input) 

BOTLIM 

The  location  in  the  ISORT  array  of  the  first  word  of  the  first  entry  to  be 
sorted.  (Integer,  Input) 

TOPLIM 

The  location  in  the  ISORT  array  of  the  last  word  of  the  last  entry  to  be 
soiled.  (Integer,  Input) 

KEYPOS 

The  column  in  the  table  of  the  first  word  of  the  1  or  two  word  character 
field  on  which  the  sort  occurs.  It  must  be  a  value  between  1  and  TOTLEN. 
(Integer,  Input) 

TOTLEN 

The  length  in  single-precision  words  of  one  table  row  (Integer,  Input) 

HEYLEN 

The  number  of  characters  in  the  hollerith  string.  Must  be  either  four  or 
eight.  If  it  is  not  four,  it  is  assumed  to  be  eight  without  warning.  (Integer, 
Input) 

Method: 

The  UTCSRT  routine  uses  a  QUICKSORT  algorithm  out  lined  in  "The  Art  Of  Computer  Programming, 
Volume  3  /  Sorting  And  Searching”  by  D.E.  Knuth,  Page  116.  Several  improvements  have  been  made 
over  tbs  pure  quicksort  algorithm.  The  first  is  a  random  selection  of  the  key  value  around  which  the 
array  is  sorted.  This  feature  allows  this  routine  to  handle  partially  sorted  information  more  rapidly  than 

the  pure  quicksort  algorithm.  The  second  improvement  in  this  routine  is  that  a  cutoff  array  length  is 
used  to  direct  further  array  sorting  to  an  insert  sort  algorithm  (Ibid.  Page  81).  This  method  has  proven 
to  be  more  rapid  than  allowing  small  arrays  to  be  sorted  by  the  quicksort  algorithm.  Presently  this  cutoff 
length  is  set  at  15  entries.  Studies  should  be  conducted  on  each  type  of  machine  'n  order  to  set  this  cutoff 
length  to  mnrimize  the  speed  of  this  routine.  This  sorting  algorithm  requires  a  integer  stack  in  which 
to  place  link  information  during  the  sort.  The  maximum  required  size  for  this  stack  array  in  twice  (he 
natural  log  of  the  number  of  rows  in  the  table.  At  present,  the  UTCSRT  routine  has  hard  coded  an  array 
of  size  (2,40)  which  provides  for  1  trillion  entries  to  be  sorted. 

Design  Requirement?:; 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTEXIT 

Entry  Point:  UTEXIT 

Purpose: 

lb  terminate  the  execution  of  the  system  when  an  error  occurs. 

MAPOL  Calling  Sequence: 

CALL  EXIT; 

Application  Calling  Sequence: 

CALL  UTEXIT 

Method: 

The  utexit  routine  is  called  to  cleanly  terminate  the  execution  of  the  ASTROS  system.  It  callB  the 
dbterm  database  termination  program  to  provide  for  normal  closing  of  the  database  files,  and  dumps 
the  queued  messages  from  the  UTMMRT  utility.  When  these  tasks  have  been  completed,  the  program 
execution  is  terminated. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTGPRT 

Entry  Point:  UTGPRT 

Purpose: 

lb  print  to  the  system  output  file  the  contents  of  special  database  matrix  entities  that  have  rows 
associated  with  structural  degrees  of  freedom. 

MAPOL  Calling  Sequence: 

CALL  UTGPRT  (  BCID,  USET(BCID) ,  MAT1,  MAT2,  MAT10  ) 

BCID  is  the  desired  boundary  condition  number 

USET  is  the  entity  defining  structural  sets 

MATi  the  matrix  name  (up  to  10) 

Application  Calling  Sequence: 

None 

Method: 

The  matrix  names  are  tested  against  the  list  of  supported  matrices.  If  the  matrix  entity  matches  one  of 
the  supported  entities  it  is  printed  in  a  format  based  on  the  structural  degrees  of  freedom  (similar  to 
displacement  and  eigenvector  output  from  OFP).  If  the  matrix  name  is  not  recognized,  a  call  to  OTJfiPRT 
is  made  instead  to  print  the  matrix  out  in  standard  banded  format  The  print  format  results  in  one  line 
of  output  for  each  grid  or  scalar  point  in  the  structural  model  for  each  column  of  the  matrix.  Each  line 
of  output  contains  one  value  for  each  of  the  (up  to)  six  degrees  of  freedom  associated  with  it. 

Design  Requirements: 

I.  Only  certain  g-size  matrices  are  printable  in  the  format  of  this  routine.  The  currently  available 
matrices  are:  drug,  dmcg,  dfvj,  dug,  dpgv,  dugv,  dpthvi,  dpgkvi,  PG.and  DFDG.  Other 
matrices  used  in  this  routine  will  result  in  a  call  to  the  UTMPRT  utility. 

Error  Conditions: 

None 


266 


Application  Utility  Module:  UTMCOR 
Entry  Point:  UTMCOR 


Purpose: 

A  special  purpose  utility  to  write  an  error  message  that  insufficient  open  core  is  available  in  a  functional 
module. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UTMCOR  (  MORCOR,  TYPE,  SUBHAM  ) 

morcor  Integer  containing  the  number  of  entries  of  type  TYPE  requested  in  the 

module  terminating  execution.  (Integer,  Input) 

TYPE  String  identifying  the  type  of  data  entries  requested: 

=  RSP  for  real,  single-precision 
=  RDP  for  real,  double-precision 
=  CSP  for  complex,  single-precision 
=  CDP  for  complex,  double-precision 
=  char  for  character  data  (Character,  Input) 

SUBNAM  A  character  string  containing  the  name  of  the  module  or  subroutine  that 

is  terminating  execution. 

Method: 

The  UTMCOR  utility  does  an  MMSTAT  call  to  determine  the  maximum  available  open  core.  The  TYPE  FLAG 
is  used  to  determine  how  many  single-precision  words  are  needed  to  satisfy  the  request  for  MORCOR 
entries.  The  difference  between  the  required  space  and  the  maximum  contiguous  memory  is  used  in  a 
call  to  utmwrt  specifying  the  number  of  additional  words  needed.  The  subnam  is  also  sent  to  UTMWRT  to 
identify  the  failure  more  precisely.  Note  that  type^cear  is  treated  by  UTMCOR  as  equivalent  to  RSP;  the 
programmer  must  factor  the  number  of  words  per  entry  and  input  MORCOR  appropriately  factored.  After 
calling  the  message  write  utility,  UTMCOR  calls  the  UTEXIT  utility  to  terminate  the  execution. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTMINT 

Entry  Point:  UTMINT 

Purpose: 

Aspscial  purpose  utility  to  initialize  a  matrix  entity  of  the  machine  precision  to  a  diagonal  or  null  matrix. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UTMINT  {  MATNAM,  VAL,  NRO%s ,  NCOLS  ) 

matnam  Character  name  of  matrix  entity  to  be  initialized.  (Character,  Input) 

VAL  Single  precision  real  value  to  initialize  diagonal  terms.  ( Real,  Input ) 

nrows  The  number  of  rows  to  be  initialized.  (Integer,  Input) 

NCOLS  The  number  of  columns  to  be  initialized.  (Integer,  Input) 

Method: 

The  UTMINT  uses  the  double  function  to  determine  if  the  matrix  to  be  initialized  is  single  or 
double-precision.  The  requested  entity  is  then  opened  and  flushed.  No  check  is  made  to  ensure  that  the 
requested  matrix  exists.  Based  on  the  value  of  VAL,  one  of  several  paths  through  the  utility  is  taken.  If 
VAL  is  not  zero,  a  diagonal  matrix  with  diagonal  terms  given  the  value  of  VAL  is  created.  If  the  non-zero 
value  is  1.0  and  nrows  equals  NCOLS,  the  resulting  identity  matrix  is  specifically  declared  as  such  in 
the  MJOCNIT  call.  If  the  matrix  is  rectangular,  extra  columns,  if  any,  are  null.  If  VAL  is  zero,  a  null  matrix 
of  the  requested  row  and  column  d-mensions  is  created.  Note  that  all  the  matrices  created  by  this  utility 
are  of  the  machine  precision  as  determined  by  the  DOUBLE  function. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTMPRG ,  UTRPRG ,  UTUPRG 

Entry  Point:  UTXPRG 

Purpose: 

Tb  purge  the  contents  of  database  entities  but  leave  the  entity  in  existence. 

MAPOL  Calling  Sequence: 

CALL  UTMPRG  (  MATl ,  MAT2 ,  .  .  .  ,  MAT10  )  ; 

CALL  UTRPRG  (  RSL1 ,  REL2 ,  . .  .  ,  REL10  ) ; 

CALL  UTUPRG  (  UNS1,  UNS2 ,  .  UNS10  ); 

Application  Calling  Sequence: 

CALL  DBFLSH  (  ENTITY  ) 

MATi  is  the  matrix  entity  name  (Character,  Input) 

RE  Li  is  the  relation  entity  name  (Character,  Input) 

UNSi  is  the  unstructured  entity  name  (Character,  Input) 

ENTITY  is  any  entity  name  (Character,  Input) 

Method: 

The  utmprg,  UTRPRG  and  utuprg  MAPOL  calls  are  defined  to  allow  up  to  10  entities  of  a  single  type  to 
be  purged  from  the  MAPOL  sequence.  The  application  interface  is  the  DBFLSH  routine  which  can  take 
a  single  argument  of  an  entity  name  of  any  type. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTMPRT 

Entry  Point:  UTMPRT 

Purpose: 


lb  print  the  contents  of  database  matrix  entities  to  the  system  output  file. 

MAPOL  Calling  Sequence: 

CALL  tmaPRT  (  METHOD ,  HAT1 ,  MAT2 ,  . . . ,  MAT10  ) ; 

Application  Calling  Sequence: 

CALL  UTMPRT  (  MATI,  METHOD,  XKOR,  DKOR  ) 

METHOD  is  the  print  method  selection  (optional  for  the  MAPOL  call) 

(Integer,  Input) 

MATi  is  the  matrix  entity  name  (Character,  Input) 

XKOR ,  dkor  are  the  base  address  of  the  open  core  common  in  single  and  double-preci¬ 

sion. 

Method: 

If  METHOD  is  zero  (or  absent  firom  the  MAPOL  call),  the  matrix  entity  MATi  is  printed  in  a  banded  format: 
that  is,  all  the  terms  from  the  first  non-zero  term  to  the  last  non-zero  term  (inclusive)  are  unpacked  and 
printed.  Null  columns  and  groups  of  null  columns  are  identified  as  such.  Note  that  the  MAPOL  sequence 
call  allows  for  up  to  10  matrix  entities  to  be  printed.  A  nonzero  METHOD  prints  the  column  by  string  with 
no  intervening  zeros. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTMWRT 
Entry  Point:  UTMWRT 


I 


Purpose: 

This  routine  acts  as  the  system  message  writer.  It  queues  error  messages  to  a  temporary  file  for 
subsequent  printing  to  the  output  file.  TheMSGDMP  utility  is  used  to  actually  print  the  queued  messages. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UTMWRT  (  LEVEL,  NUMBER,  ARGMTS  ) 

level  Severity  level  of  the  message 

<  0  No  message  header  is  written 
«  0  General  Information 
-  1  System  Fatal  Message 

*  2  User  Information  Message 

*  3  User  Warning  Message 
=  4  User  Fatal  Message 

NUMBER  Text  string  containing  the  message  number  in  the  form:  NN.Mi.LL 

ARQMTS  Tbxt  array  containing  arguments  for  the  message  text. 

Method: 

The  utmwrt  routine  cracks  the  message  number  NUM3ER  into  its  three  component  integers:  NN,  the 
module  number,  MM,  the  message  number,  and  <uL,  the  message  lengthen  records).  If  LL  is  omitted  (ie 
NUMBER~NN.MM),  it,  defaults  to  one  record  in  length. 

The  correct  message  text  is  then  recovered  from  the  message  tile  by  querying  the  ms  GLEN  for  the  module 
HN  to  obtain  the  starting  record  and  adding  the  message  number  (tM)  and  message  length  (LL)  to  obtain 
the  record  numbers  where  the  message  text  is  stored.  The  message  text  is  of  the  form: 

' - text - $ - text — $ — . ' 

If  any  $  (dollar  signs)  exist  in  the  message  text,  they  are  replaced  by  the  ARGMTS  supplied  in  the  call 
statement.  Note  that  the  final  message  text  including  the  ARGMTS  must  be  leas  than  128  characters  in 
length. 

Design  Requirements: 

1.  The  pointers  to  the  system  database  entity  that  contains  the  error  message  texts  for  each  "module’1 
must  be  stored  in  memory.  Currently,  the  array  for  pointer  storage  is  200  words  long  which  meanr 
that  no  more  than  100  distinct  "modules"  can  be  defined.  Note  that  this  does  not  imply  any  limit  on 
the  number  of  error  messages  within  a  particular  module’s  group  of  messages. 
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Error  Conditions: 


1.  otmwrt  error:  the  number  of  modules  exceeds  the  limit  of  $.  This  message  results  in  program 
termination  and  can  only  be  fixed  by  increasing  the  size  of  the  message  pointer  storage  array. 

2.  Error  in  tTCMWRT  when  processing  message  number  $.  This  message  is  a  system  level  error  which 
usually  implies  that  a  non  valid  message  number  NN.  MM.  liL  was  passed  to  the  module. 

3.  If  the  resultant  message  is  longer  than  128  characters,  the  unexpanded  text  is  printed  (with  $’s) 
and  the  arguments  are  echoed. 


272 


Application  Utility  Module:  UTPAGE ,  UTPAG2 

Entry  Points:  UTPAGE ,  UTPAG2 

Purpose: 

Tb  handle  paging  of  the  system  output  file  during  execution  of  the  system.  UTPAG2  performs  a  page  eject 
based  on  an  anticipated  number  of  lines  to  print. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UTPAGE 
CALL  UTPAG2  {  N  ) 

N  Number  of  lines  that  will  be  printed.  (Integer,  Input) 

ARC3STS  Ttext  array  containing  arguments  for  the  message  text. 

Method: 

The  UTPAGE  routine  keeps  track  of  the  total  line  count  and  the  line  count  for  the  current  page.  The  total 
number  of  output  lines  allowed  is  maintained  for  use  by  this  module.  These  quantities  are  stored  in  the 
OUTPT1  common  block.  The  OUTPT2  common  block  is  also  used  to  store  the  header  and  titling  data  for 
the  current  execution.  When  output  to  the  system  output  file  is  being  performed,  the  line  count  is  checked 
by  the  current  module  against  the  number  of  lines  per  page,  when  the  maximum  lines  per  page  is 
reached,  a  call  to  UTPAGE  causes  a  page  advance  on  the  system  output  file  and  the  total  number  of 
printed  lines  is  updated.  The  header  information  can  be  modified  by  the  application  modules  by  simply 
overwriting  the  current  entries  in  the  OUTPT2  common  block.  Note  that  all  system  output  should  be 
performed  using  this  utility  module. 

The  UTPAG2  routine  performs  a  page  eject  if  the  N  lines  will  not  fit  on  the  current  page. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTRPRT 

Entry  Point:  UTRPRT 

Purpose: 

lb  print  the  contents  of  database  relational  entities  to  the  system  output  file. 

MAPOL  Calling  Sequence: 

CALL  UTRPRT  (  REL1 ,  REL2 ,  .  .  .  ,  REL10  ) 

Application  Calling  Sequence: 

CALL  UTRPRT  (  REL,  IKOR,  RKOR,  DKOR  ) 

rel  is  the  name  of  the  relation  to  be  printed. 

IKOR, RKOR,  are  open  core  base  addresses  in  integer,  real  and  double-precision. 

DKOR 

Method: 

The  relational  entity  RELi  is  printed  using  the  full  relation  projection.  At  present,  if  the  full  projection 
is  too  large  to  be  output  on  one  132  character  record,  the  remaining  attributes  are  ignored.  Each 
attribute,  regardless  of  type,  uses  a  12  character  format  for  output.  The  current  version  of  UTRPRT  has 
a  few  additional  restrictions.  The  first  is  that  any  string  attribute  that  is  not  eight  characters  in  length 
cannot  be  printed.  The  routine  will  ignore  these  attributes  and  write  a  message  to  that  effect.  In  addition, 
double-precision  attributes  are  first  converted  to  single-precision  before  output. 

Design  Requirements: 

1.  Only  the  following  attribute  types  are  supported: 

INT,  KINT,  AINT 
RSP,  ARSP 
RDP 

STR,  KSTR  (up  to  8  characters) 

Error  Conditions: 

1.  Relational  entity  REL  does  not  exist. 

2.  Relational  entity  REL  is  empty. 

3.  A  string  attribute  cannot  be  printed  when  longer  than  the  string  limit  eight  characters. 
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Application  Utility  Module:  UTRSRT 

Entry  Point:  UTRSRT 

Purpose: 

Tb  sort  a  table  of  numbers  on  a  real  column  of  the  table 
MAPOL  Calling  Sequence: 

None 


Application  Calling  Sequence: 


CALL  UTRSRT 

(  ISORT,  ITBROW,  BOTLIM,  TOPLIM,  KEYPOS,  TOTLEN  ) 

ISORT 

Array  to  be  sorted  (Any,  Input) 

ITBROW 

An  array  of  length  TOTLEN  single-precision  words  used  to  store  a  table 
row  (Any,  Input) 

BOTLIM 

The  location  in  the  ISORT  array  of  the  first  word  of  the  first  entry  to  be 
sorted.  (Integer,  Input) 

TOPLIM 

The  location  in  the  ISORT  array  of  the  last  word  of  the  last  entry  to  be 
sorted.  (Integer,  Input) 

KEYPOS 

The  column  in  the  table  on  which  the  sort  occurs.  It  must  be  a  value  be¬ 
tween  1  and  TOTLEN.  (Integer,  Input) 

TOTLEN 

Method: 

The  length  in  single-precision  words  of  one  table  row  (Integer,  Input) 

The  UTRSRT  routine  uses  a  QUICKSORT  algorithm  outlined  in  "The  Art  Of  Computer  Programming, 
Volume  3  /  Sorting  And  Searching"  by  D.E.  Knuth,  Page  116.  Several  improvements  have  been  made 
over  the  pure  quicksort  algorithm.  The  first  is  a  random  selection  of  the  key  value  around  which  the 
array  is  sorted.  This  feature  allows  this  routine  to  handle  partially  sorted  information  more  rapidly  than 
the  pure  quicksort  algorithm.  The  second  improvement  in  this  routine  is  that  a  cutoff  array  length  is 
used  to  direct  further  array  sorting  to  an  insert  sort  algorithm  (Ibid.  Page  81).  This  method  has  proven 
to  be  more  rapid  than  allowing  small  arrays  to  be  sorted  by  the  quicksort  algorithm.  Presently  this  cutoff 
length  is  set  at  15  entries.  Studies  should  be  conducted  on  each  type  of  machine  in  order  to  set  this  cutoff 
length  to  maximize  the  speed  of  this  routine.  This  sorting  algorithm  requires  a  integer  stack  in  which 
to  place  link  information  during  the  sort.  The  maximum  required  size  for  this  stack  array  in  twice  fee 
natural  log  of  the  number  of  rows  in  the  table.  At  present,  the  UTPSRT  routine  has  hard  coded  an  array 
of  size  (2,40)  which  provides  for  1  trillion  entries  to  be  sorted. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTSFLG,  UTSFLR,  UTGFLG,  UTGFLR 
Entry  Points:  UTSFLG,  UTSFLR,  UTGFLG,  UTGFLR 


Purpose; 

These  routines  set  a  named  flag  to  an  integer  value,  real  value,  cr  retrieve  a  value  previously  set. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UTSFLG {  INNAME  ,  INVAL  ) 

CALL  UTSFLR  (  INNAME  ,  INVAIR  ) 

CALL  UTGFLG {  INNAME  ,  OUTVAL  ) 

CALL  UTGFLR (  INNAME  ,  OUTVLR  ) 

INNAME 

INVAL 

INVALR 

OUTVAL 

OUTVLR 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
Notes: 

1.  Routine  setsys  uses  UTSFLG  to  set  output  file  unit  number,  PRINT  (set  to  second  word  of  /UNITS/ 
from  JOCED)  and  to  set  the  system  precision  PREC  (*1  for  single-precision;  =2  for  double-precision) 
based  on  the  double  function.  Large  matrix  utilities  fetch  these  flag  values  by  using  UTGFLG. 

2.  Some  of  the  debug  parameters  are  set  by  UTSFLG  and  are  retrieved  by  the  application  modules  using 
UTGFLG. 

3.  Routine  timccm  uses  utsflr  to  set  system  timing  constants  for  matrix  operations.  The  flags  are 
named:  TMUNIO,  MMXPT,  IMMXUT,  rnCCPK,  TMM2UP,  TMHKUM,  TfcHmi,  TMTRSP,  TMTRDP, 
TMTC3P,  3MTCDP,  TMLRSP,  TMLRDP,  IMLCSP,  TMLCDP,  IMCRSP,  t3SCRD?,  TMCCSP,  and  TMCCDP. 
Large  Matrix  utilities  fetch  these  constants  by  using  UTGFLR. 


The  name  of  the  FLAG  to  set  (Character, Input) 
The  value  to  set  for  the  flag  (Integer, Input) 
The  value  to  set  for  the  FLAG  (Real, Input) 

The  current  value  of  the  FLAG  (Integer, Output) 
The  current  value  of  the  FLAG  (Real, Output) 
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Application  Utility  Module:  UTSORT 

Entry  Point  UTSORT 

Purpose: 


lb  sort  a  table  of  data  on  an  integer  column  of  the  table 
MAPOL  Casing  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UTSORT  {  I  SORT,  ITBRCW,  BCTLIM,  TOPLIM,  SU5YPOS,  TOTLEH  } 

Array  to  be  sorted  (Any,  Input) 

An  array  of  length  TOTLEH  single-precision  words  used  to  store  a  table 
row  (Any.  Input) 

The  location  in  the  I30RT  array  of  the  first  word  of  the  first  entry  to  be 
sorted.  (Integer,  Input) 

The  location  in  the  isort  array  of  the  last  word  of  the  last  entry  to  be 
sorted.  (Integer,  Input) 

The  column  in  the  table  on  which  the  sort  occurs.  It  must  be  a  value  be¬ 
tween  1  and  TOTLEST.  (Integer,  Input) 

The  length  in  single-precision  words  of  one  table  row  (Integer,  Input) 


The  UTSORT  routine  uses  a  QUICKSORT  algorithm  outlined  in  ’’The  Art  Of  Computer  Programming, 
Volume  3  /  Sorting  And  Searching”  by  D.E.  Knuth,  Page  116.  Several  improvements  have  been  made 
over  the  pure  quicksort  algorithm.  The  first  is  a  random  selection  of  the  key  value  around  which  the 
array  is  sorted.  This  feature  allows  this  routine  le  handle  partially  sorted  information  more  rapidly  than 
the  pure  quicksort  algorithm.  The  second  improvement  in  this  routine  is  that  a  cutoff  array  length  is 
used  tc  direct  further  array  sorting  to  an  insert  ?  Jri  algorithm  (Ibid.  Page  81).  This  method  has  proven 
to  be  more  rapid  than  allowing  small  arrays  to  be  sorted  by  the  quicksort  algorithm.  Presently  this  cutcff 
length  is  set  at  16  entries.  Studies  should  be  conducted  on  each  type  of  machine  in  order  to  set  this  cutoff 
length  to  maximize  the  speed  of  this  routine.  This  sorting  algorithm  requires  a  integer  stack  in  which 
to  place  link  information  during  the  sort.  The  maximum  *equ*red  size  for  this  stack  array  in  twice  the 
natural  log  of  the  number  of  rows  in  the  table.  At  present,  the  UTSORT  routine  has  hard  coded  an  array 
of  size  (2,40)  which  provides  for  1  trillion  entries  to  be  sorted. 

Design  Requirements: 

None 

a  Conditions: 

None 


ISORT 
I THROW 

BOTLIM 

TOPLIM 

KEVPOS 

TOTLEN 


Method: 
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Application  Utility  Module:  UTSRCH 


I 


Entry  Point:  UTSRCH 
Purpose: 

Search  a  table  of  values  for  an  integer  key  from  a  table  that  is  in  sorted  order  on  that  integer  key. 
Application  Calling  Sequence: 

naunim — — — mmm m  «■  w^ynani'^ iw«iiiHoai>M 

CALL  CTSRCE  {  *ESR,  KEY,  LIST,  LENT,  L3TLEN,  IHCR  ) 

-BSR  Error  return  if  the  X3Y  value  is  not  found  in  the  LIST. 

KEY  Value  being  searched  for  in  the  LIST.  (Integer,  Input) 

LIST  Array  in  which  the  KEY  should  be  located.  (Any,  Input) 

LPHT  On  input,  the  pointer  to  the  lowest  key  value  in  the  LIST .  On  output, 

pointer  to  the  matching  value  in  the  LIST.  (Integer) 

L3TLEH  Length  of  the  list  including  XKCR  - 1  trailing  values  following  the  last  key. 

(Integer,  Input) 

ircr  The  spacing  in  the  list  between  key  values.  (Integer,  Input) 

Method: 

The  UTSRCH  routine  first  calculates  the  number  of  key  values  to  be  searched.  If  there  are  less  than  a 
minimum  number  of  key  values  (presently  16),  then  the  list  i3  searched  sequentially.  If  more  than  the 
minimum  artist,  a  binary  search  of  the  list  is  perib  lined.  If  the  value  cannot  be  found,  the  routine  returns 
to  *ERR. 


i 


Design  Requirements: 
None 

Error  Conditions: 
None 


( 
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Application  Utility  Module:  UTSRT3 

Entry  Point:  UTSRT3 

Purpose: 

Sort  a  table  on  one  to  three  integer  keys. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UTSRT3  (  Z,  NENT,  LENT,  ZZ,  KEY1 ,  LKEY1,  KEY 2 ,  LKEY2 ,  SCKY3,  LKEY3,  TYPE  ) 

Z  Array  to  be  sorted.  (Any,  Input) 

KENT  Tlie  number  of  rows  (entries)  in  z.  (Integer,  Input) 

lent  The  number  of  words  in  each  row  of  z  (Integer.  Input) 

ZZ  An  array  of  length  LENT  to  be  used  as  intermediate  storage. 

(Integer,  Input) 

KEYl  Word  offset  in  Z  for  the  first  key  on  which  to  sort.  KEY!  must  be  in  the 

range  1  to  LENT.  (Integer,  Input) 

LKEY1  Number  of  words  in  the  first  key  on  which  to  sort;  use  0  if  KEY  is  not 

used.  KEY1  +  LREY1  must  be  less  than  LENT  (Integer,  Input) 

LKEY2  Number  of  words  in  the  second  key  on  which  to  sort;  use  0  if  KEY  is  not 

used.  KEY 2  +  LKEY2  must  be  less  than  LENT  (Integer,  Input) 

LKEY3  Number  of  words  in  the  third  key  on  which  to  sort,  use  0  if  KEY  is  not 

used.  KEY 3  +  LKEY3  must  be  less  than  lent  (Integer,  Input) 

TYPE  Type  of  sort  to  perform.  (Integer,  Input) 

>  0  for  sorting  in  increasing  order 
<  Q  for  sorting  in  decreasing  order 

Method: 

The  UTSRT3  routine  sorts  each  key  in  order  from  one  to  three,  with  multiple-word  keys  being  treated 
as  though  they  were  distinct  integer  keys  on  which  the  ascending  or  descending  sort  is  performed. 

Design  Requirements: 

1.  There  is  an  implementation  limit  of  no  more  than  200  total  keys. 

LK3Y1  +  LKEY2  +  LKEY3  <  201 

Error  Conditions: 

1.  Ibo  many  sort  keys  cause  ASTROS  termination. 
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Application  Utility  Module:  UTSRTD 
Entry  Point:  UTSRTD 
Purpose: 


Sort  a  vector  of  double-precision  numbers. 

MAFOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  OTS9TD  (  2,  BOTLIM,  TOPLIM  ) 

2  Double  precision  array  to  be  sorted.  (Double,  Input) 

BOTLIM  The  location  in  the  2  array  of  the  first  entry  to  be  sorted.  (Integer,  Input) 

toplim  The  location  in  the  2  array  of  the  iast  entry  to  be  sorted.  (Integer,  Input) 

Method: 

The  UTSRTD  routine  uses  a  QUICKSORT  algorithm  outlined  in  The  Art  Of  Computer  Programming, 
Volume  3  /  Sorting  And  Searching"  by  D.E.  Knuth,  Page  116.  Several  improvements  have  been  made 
over  the  pure  quicksort  algorithm.  The  first  is  a  random  selection  of  the  key  value  around  which  the 
array  is  sorted.  This  feature  allows  this  routine  to  handle  partially  sorted  information  more  rapidly  than 
the  pure  quicksort  algorithm  The  second  improvement  in  this  routine  is  that  a  cutoff  array  length  is 
used  to  direct  further  array  sorting  to  an  insert  sort  algorithm  (Ibid.  Page  81).  This  method  has  proven 
to  be  more  rapid  than  allowing  small  arrays  to  be  sorted  by  the  quicksort  algorithm.  Presently  this  cutoff 
length  is  set  at  15  entries.  Studies  should  be  conducted  on  each  type  of  machine  in  order  to  set  this  cutoff 
length  to  maximize  the  speed  of  this  routine.  The  algorithm  used  in  this  utility  requires  a  stack  array 
for  storing  the  Unking  information  generated  during  the  sort.  The  maximum  size  needed  for  this  stack 
is  twice  the  natural  !og  of  the  number  of  entries  in  the  array.  Currently,  a  stack  of  dimension  (2,40)  is 
hard  coded  which  allows  for  a  trillion  entries  to  be  sorted. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTSRTI 

Entry  Point:  UTSRTI 

Purpose: 

Sort  a  vector  of  integers. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UTSRTI  (  Z,  BOTLIM,  TOPLIM  ) 

Z  Integer  array  to  be  sorted.  (Integer,  Input) 

botlim  The  location  in  the  Z  array  of  the  first  entry  to  be  sorted.  (Integer,  Input) 

TOPLIM  The  location  in  the  z  array  of  the  last  entry  to  be  sorted.  (Integer,  Input) 

Method: 

The  UTSRTI  routine  uses  a  QUICKSORT  algorithm  outlined  in  "The  Art  Of  Computer  Programming, 
Volume  3  /  Sorting  And  Searching"  by  D.E.  Knuth,  Page  116.  Several  improvements  have  been  made 
over  the  pure  quicksort  algorithm.  The  first  is  a  random  selection  of  the  key  value  around  which  the 
array  is  sorted.  This  feature  allows  this  routine  to  handle  partially  sorted  information  more  rapidly  than 
the  pure  quicksort  algorithm.  The  second  improvement  in  this  routine  is  that  a  cutoff  array  length  is 
used  to  direct  further  array  sorting  to  an  insert  sort  algorithm  (Ibid.  Page  81).  This  method  has  proven 
to  be  more  rapid  than  allowing  small  arrays  to  be  sorted  by  the  quicksort  algorithm.  Presently  this  cutoff 
length  is  set  at  15  entries.  Studies  should  be  conducted  on  each  type  of  machine  in  order  to  set  this  cutoff 
length  to  maximize  the  speed  of  this  routine.  The  algorithm  used  in  this  utility  requires  a  stack  array 
for  storing  the  linking  information  generated  during  the  sort.  The  maximum  size  needed  for  this  stack 
is  twice  the  natural  log  of  the  number  of  entries  in  the  array.  Currently,  a  stack  of  dimension  (2,40)  is 
hard  coded  which  allows  for  a  trillion  entries  to  be  sorted. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTSRTR 
Entry  Point:  UTSRTR 


Purpose: 

Sort  a  vector  of  real  numbers. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CAXJL  UTSRTR  {  Z,  BOTLIM,  TOPLIM  ) 

Z  Real  array  to  be  sorted.  (Real,  Input) 

BOTLIM  The  location  in  the  Z  array  of  the  first  entry  to  be  sorted.  (Integer,  Input) 

toplim  The  location  in  the  z  array  of  the  last  entry  to  be  sorted.  (Integer,  Input) 

Method: 

The  UTSRTR  routine  uses  a  QUICKSORT  algorithm  outlined  in  "The  Art  Of  Computer  Programming, 
Volume  3  /  Sorting  And  Searching"  by  D.E.  Knuth,  Page  116.  Several  improvements  have  been  made 
over  the  pure  quicksort  algorithm.  The  first  is  a  random  selection  of  the  key  value  around  which  the 
array  is  sorted.  This  feature  allows  this  routine  to  handle  partially  sorted  information  more  rapidly  than 
the  pure  quicksort  algorithm.  The  second  improvement  in  this  routine  is  that  a  cutoff  array  length  is 
used  to  direct  further  array  sorting  to  an  insert  sort  algorithm  (Ibid.  Page  81).  This  method  has  proven 
to  be  more  rapid  than  allowing  small  arrays  to  be  sorted  by  the  quicksort  algorithm.  Presently  this  cutoff 
length  is  set  at  15  entries.  Studies  should  be  conducted  on  each  type  of  machine  in  order  to  set  this  cutoff 
length  to  maximize  the  speed  of  this  routine.  The  algorithm  used  in  this  utility  requires  a  stack  array 
for  storing  the  linking  information  generated  during  the  sort  The  maximum  size  needed  for  this  stack 
is  twice  the  natural  log  of  the  number  of  entries  in  the  array.  Currently,  a  stack  of  dimension  (2,40)  is 
hard  coded  which  allows  for  a  trillion  entries  to  be  sorted. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTS  TOD,  UTDTOS 

Entry  Point:  UTSTOD,  UTDTOS 

Purpose: 

Tb  convert  a  number  of  entries  from  single-precision  to  double-precision  and  copy  them  from  one  array 
into  another  and  to  convert  a  number  of  entries  from  double-precision  to  single-precision  and  copy  them 
from  one  array  into  another. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UTSTOD  (  RZ,  DZ,  TOTLESf  ) 

CALL  UTDTOS  (  DZ,  RZ,  TOTLSM  ) 

RZ  Real  array 

DZ  Double  precision  array 

totlen  Length  of  array  (Integer,  input) 

Method: 

For  or 3 tod  ,  TOTLE&  entries  of  array  RZ  are  copied  to  DZ  and  converted  to  double-precision. 
Similarly,  for  dtdtos,  the  entries  of  DZ  are  copied  to  RZ . 

Design  Requirements: 

None 

Error  Conditions: 

None 


283 


Application  Utility  Module:  UTUPRT 
Entry  Point:  UTUPRT 


Purpose: 

lb  print  the  contents  of  database  unstructured  entities  to  the  system  output  file. 

MAPOL  Calling  Sequence: 

CALL  UTOPRT  (  ENTNAM,  TYPE  ) 

Application  Calling  Sequence: 

None 

Method: 

The  unstructured  entity  ENTNAM  is  printed  to  the  system  output  file  using  the  format  specified  by  TYPE. 
The  available  forma's  fcr  output  are:  0,  for  Integer,  1  for  Real,  and  2  for  Double  Precision. 

Design  Requirements: 

None 

Error  Conditions: 

1.  Unstructured  entity  ENTNAM  does  not  exist. 

2.  Unstructured  entity  entnam  is  empty. 

3.  Invalid  unstructured  type  $  in  UTOPRT  print  request  for  entity  $.  Valid  types  are:  0 ,  1,  2  (INT, 
RSP,  RDP;  respectively) 
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Application  Utility  Module:  UTZERD 

Entry  Point:  UTZERD 

Purpose: 

Tb  initialize  the  contents  of  an  array  with  a  specified  double-precision  value. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UTZERD  (  ARRAY,  NWORDS,  VALUE  ) 

Method: 

NWORDS  of  array  ARRAY  are  initialized  with  the  value  VALUE.  Note  that  VALUE  and  ARRAY  must  be 
double-precision. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  UTZERS 

Entry  Point:  UTZERS 

Purpose: 

lb  initialize  the  contents  of  an  array  with  a  specified  integer  or  real  value. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UTZERS  (  ARRAY,  NWORDS,  VALUE  ) 

Method: 

nwords  of  array  ARRAY  are  initialized  with  the  value  VALUE.  Both  ARRAY  and  value  must  be 
single-precision 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Application  Utility  Module:  XISTOI 

Entry  Point:  XISTOI 

Purpose: 

Tb  convert  a  string  to  its  integer  equivalent. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  XISTOI  (  STR,  I VALUE,  RC  ) 

SIR  Character  string  representing  an  integer  number  (Input) 

IVALUE  Resulting  integer  number  (Output) 

rc  Return  Code  (Output) 

*  0  if  str  contained  a  legal  integer 

*  1  if  str  contained  an  illegal  character 

»  2  if  STR  contained  an  illegal  integer  (overflow) 

Method: 

The  character  string  str  is  cracked  one  digit  at  a  time  with  error  checks  made  against  the  machine 
maximum  integer  to  ensure  that  the  resultant  IVALUE  is  a  legal  integer. 

Design  Requirements: 

1.  Legal  strings  may  contain  plus  (+),  minus  (-)  and  one  or  more  decimal  digits  from  0  through  9. 
Error  Conditions: 

1.  Rei  urn  codes 
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Application  Utility  Module:  XISTOR 
Entry  Point:  XISTOR 


Purpose: 

lb  convert  a  string  to  its  real  equivalent. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  XISTOR  (  STR,  VALUE,  RC  ) 

STR  Character  string  representing  a  real  number  (Input) 

VALUE  Resulting  real  number  (Output) 

RC  Return  Code  (Output) 

-  0  if  STR  contained  a  legal  real  number 

*  1  if  STR  contained  an  illegal  character 
™  2  if  str  contained  an  overflow  value 

*  3  if  STR  contained  an  underflow  value 

Method: 

The  character  string  STR  is  cracked  into  its  three  component  parts:  the  leading  whole  number,  the 
fractional  digits  and  the  exponential  whole  number.  Each  of  the  these  pieces  is  optional.  The  three  parts 
are  then  combined  to  form  the  real  number. 

Design  Requirements: 

1.  Legal  strings  may  contain  plus  (+),  minus  (-) ,  one  or  more  decimal  digits  from  0  through  9  and  E 
or  D  and  must  contain  a  decimal  point  (.). 

2.  The  Bulk  Data  style  of  real  number  representation  is  fully  supported  as  is  the  FORTRAN  E,  F  and 
G  formats. 

Error  Conditions: 

1.  Return  codes 
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7.  LARGE  MATRIX  UTILITY  MODULES 


Finite  element  structural  analysis,  which  forms  the  core  of  the  ASTROS  system,  requires  a  suite 
of  utilities  for  matrix  operation0  which  are  able  to  efficiently  handle  very  large,  often  sparse,  matrices. 
This  section  is  devoted  to  the  documentation  of  the  large  matrix  utilities  in  ASTROS,  the  designation 
large  comes  from  the  assumption  made  by  each  of  these  utilities  that  the  relevant  matrices  are  stored  on 
the  CADBB  database  and  will  be  operated  on  in  a  fashion  that  allows  them  to  be  of  arbitrary  order.  Other 
matrix  operations  are  available  in  the  general  utility  library  documented  in  Section  6  for  small  matrices 
stored  in  memory  The  suite  of  large  matrix  utilities  in  ASTROS  includes  partition/merge  operations, 
decomposition  and  forward/backward  substitutions,  multiply/add  and  pure  addition  operations,  transpose 
operations  and  real  and  complex  eigenvalue  extraction. 

The  following  subsections  document  the  interface  to  the  large  matrix  utilities  in  two  formats: 
using  the  executive  system  (MAPOL)  and  using  the  FORTRAN  calling  sequence.  In  some  cases,  the 
MAPOL  language  supports  the  particular  matrix  operation  directly.  In  such  cases,  the  user  need  not 
make  a  call  to  the  particular  utility,  instead,  the  MAPOL  compiler  automatically  generates  the  correct 
call  to  the  appropriate  utility.  These  direct  interfaces  are  so  indicated  in  the  documentation. 
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Large  Matrix  Utility  Module:  cdcomp 

Entry  Point:  CDCOMP 

Purpose: 

lb  decompose  a  complex  square  matrix  [A]  into  its  upper  and  lower  triangular  factors: 

[A]  -  [L]  [U] 

MAPOL  Calling  Sequence: 

CALL  DECOMP  (  [A]  ,  £L]  ,  [0]  )  ; 

Note  that  the  calling  sequence  for  CDCCMP  is  through  the  MAPOL  DECOMP  module.  The  method  is 
automatically  selected  if  the  input  matrix  is  complex. 

Application  Calling  Sequence: 

CALL  CDCOMP  (A,  L,  0,  XKOR,  RKOR,  DROR) 

[A]  The  matrix  to  be  decomposed  (Input,  Character) 

[L]  The  lower  triangular  factor  (Output,  Character) 

[0]  The  upper  triangular  factor  (Output,  Character) 

IKOR ,  RKCR ,  DKOR  The  base  address  of  the  open  core  common  block  in  integer,  real,  and  dou¬ 

ble  precision  arrays,  respectively  (Input) 

Method: 

The  cdcomp  module  can  decomposes  complex  matrices.  The  resultant  lower,  [L] ,  and  upper,  [0] , 
triangular  factors  are  specially  structured  matrix  entities  having  control  information  in  the  diagonal 
terms.  They  may  only  be  reliably  used  by  the  back-substitution  module  GFBS. 

Design  Requirements: 

1.  The  back-substitution  phase  of  equation  solving  is  performed  with  module  GIBS. 

2.  The  triangular  factors  [L]  and  [0]  may  not  be  used  reliably  by  matrix  utilities  other  than  GFBS. 
Error  Conditions: 

None 
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Large  Matrix  Utility  Module:  CEIG 
Entry  Point:  CEIG 


Purpose: 

lb  solve  the  equation: 

(CM]p2  +  TB]p  +  [R]) {u}  =  0 

for  the  eigenvalues  p  and  the  associated  eigenvectors  (u)  where  [M],  [S]  and  [X]  are  mass,  damping 
and  stiffness  matrices,  respectively. 

MAPOL  Calling  Sequence: 

CALL  CEIG  (  3CID,  USET,  [KDD]  ,  [BDD]  ,  [MOD],  LAMDAC,  [CPHID]  ,  [CPHIDL]  ,  NPHX  ); 


Application  Calling  Sequence: 

CALL  CEIG  {  BCXD,  USET,  KDD,  BDD,  HDD,  LAMDAC,  CPHID,  CFHIDL,  OCEIGS, 
IXOR,  RKOR,  DKOR  ) 


EC  ID 
USET 
[KDD] 

[BDD] 

[MDD] 

LAMDAC 

[CPHID] 

[CPHIDLJ 

NPHI 

OCEIG3 

I XOR , RKOR , DKOR 

Method: 


The  boundary  condition  identification  number  (Integer,  Input) 

Entity  defining  structural  sets  for  the  current  BC 

Dynamic  stiffness  matrix  -  D-set  (Input,  Character) 

Dynamic  damping  matrix  -  D-set  (Input,  Character) 

Dynamic  mass  matrix  -  D-set  (Input,  Character) 

A  relation  entity  containing  a  list  of  extracted  complex  eigenvalues 
(Output,  Character) 

A  matrix  whose  columns  are  the  complex  eigenvectors  corresponding  to 
the  extracted  eigenvalues  (Output,  Character) 

A  matrix  containing  the  left  complex  eigenvectors  (Output,  Character) 

The  number  of  complex  eigenvectors  computed  (Output,  Integer) 

The  name  of  the  output  entity  for  statistical  information  (Character) 

The  open  core  common  base  address  for  integer,  real  and  double  precision 
arrays,  respectively  (Input) 


The  Complex  Eigenvalue  Analysis  Module  calculates  the  eigenvalues  and  eigenvectors  for  a  general 
system  which  may  have  complex  terms  in  the  mass,  damping  and  stiffness  matrices.  The  eigenvectors 
are  scaled  according  to  the  user  requested  normalisation  scheme  (MAX  or  POlNT).The  eigenvalues  p  and 
the  eigenvectors  (u)  are  always  treated  as  complex.  These  data  are  related  to  the  ud  displacements  if 
a  direct  formulation  is  used  or  are  related  to  the  uh  displacements  if  a  modal  formulation  is  used. 

Presently  the  complex  eigenvalue  analysis  is  used  by  manually  inserting  a  call  to  module  CEIG  in  the 
MAPOL  sequence.  The  relation  EIGC  wili  be  automatically  retrieved  in  module  CEIG  and  the  first 
method  that  appears  in  the  relation  will  control  the  extraction.  The  Inverse  Power  Method  or  the  Upper 
Hessenburg  Method  which  is  selected  by  Else  data  is  used  to  solve  the  eigenvalue  problem.  (Subroutines 
cikver  or  KESSl).  In  case  there  is  insufficient  core  for  Upper  Hessenburg  Method,  the  Inverse  Power 
Method  will  be  used  if  the  necessary  data  exist  on  EIGC. 
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Design  Requirements: 


1.  The  matrices  [KDD],  [3RD]  anJ  (HDD]  must  be  complex, and  matrices  [HDD]  and  [CPHIDL]  are 
not  required. 

Error  Conditions: 

1.  EIGC  is  not  in  the  Bulk  Data  packet. 

2.  [KDD]  and/or  [MDD]  do  not  exist 

3.  [KDD]  and  [MOD]  are  not  compatible. 

4.  [KDD]  is  singular  in  HESS  method. 


Large  Matrix  Utility  Module:  COLMERGE 

Entry  Point:  MXMERG 

Purpose: 

lb  merge  two  submatrices  into  a  single  matrix  [A]  column-wise: 

[A]  <—  [An  A12] 

MAPOL  Calling  Sequence: 

CALL  COLMERQE  ([A],  [An],  [Ai2]  ,  [CP]); 

Application  Calling  Sequence: 

CALL  MXMERG  (A,  All,  BLANK,  A12,  BLANK,  CP,  BLANK,  HORE) 

[A]  The  resulting  merged  matrix  (Output,  Character) 

[Ai  j  ]  The  input  partitions  as  shown  above  (Input,  Character) 

[CP]  The  column  partitioning  vector  (Input,  Character) 

blank  A  character  blank  (Input,  Character) 

KOBE  The  base  address  of  the  open  core  common  block  (Input,  Integer) 

Method: 

The  partitioning  vector  [CP]  must  be  a  column  vector  containing  zero  and  nonzero  terms.  The  [All] 
partition  will  be  placed  in  [A]  at  positions  where  [CP]  is  zero.  If  either  of  the  partitions  [All]  or 
[A12]  is  null,  it  may  be  omitted  from  the  MAPOL  calling  sequence  or  a  blank  may  be  used  in  the 
application  calling  sequence. 

The  COLPART  large  matrix  utility  module  performs  the  inverse  of  this  module. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Large  Matrix  Utility  Module:  COLPART 

Entry  Point:  MXPRTN 

Purpose: 

Tb  partition  a  matrix  [A]  into  tv  3  submatrices  column-wise: 

[A]  —3  [An  A12] 

MAPOL  Calling  Sequence: 

CALL  COLPART  <  [A]  ,  [An]  ,  [A12]  ,  [CP] )  ; 

Application  Calling  Sequence: 

CALL  MXPBTN  (A,  An,  BLANK,  A12,  BLANK,  CP,  BLANK,  KOBE) 

[A]  The  matrix  being  partitioned  (Input,  Character) 

[A15  ]  The  resulting  partitions  shown  above  (Output,  Character) 

[CP]  The  column  partitioning  vector  (Input,  Character) 

BLANK  A  character  blank  (Input,  Character) 

KOBE  The  base  address  of  the  open  core  common  block  (Input,  Integer) 

Method: 

The  partitioning  vector  [CP]  mus^,  b.>  a  column  vector  containing  zero  and  nonzero  terms.  The  [All] 
partition  will  then  contain  those  columns  of  [A?  corresponding  to  a  zoro  value  in  [CP] .  If  either  partition 
is  not  desired,  it  may  be  omitted  from  the  MAPOL  calling  sequence  or  a  BLANK  may  be  used  in  the 
application  celling  sequence. 

Design  Requirements: 

None 

E^ror  Conditions: 

None 
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Large  Matrix  Utility  Module:  DECOMP 

Entry  Point:  DECOMP 

Purpose: 

lb  decompose  a  general  square  matrix  [A]  into  its  upper  and  lower  triangular  factors: 
tA]  -  [L]  [0] 

MAPOL  Calling  Sequence: 

CALL  DECOMP  ( [A] ,  [L] ,  [U] )  ; 

Application  Calling  Sequence: 

CALL  DECCMP  (A,  L,  0,  IXOR,  RXOR,  DKOR) 

[A]  The  matrix  to  be  decomposed  (Input,  Character) 

[L]  The  lower  triangular  factor  (Output,  Character) 

[0]  The  upper  triangular  factor  (Output,  Character) 

XKOR ,  rxor  ,  DKOR  The  base  address  of  the  open  core  common  block  in  integer,  real,  and  dou¬ 

ble  precision  array's,  respectively  (Input) 

Method: 

The  decomp  module  can  decompose  both  real  and  complex  matrices.  The  resultant  lower,  [L] ,  and  upper, 
[U] ,  triangular  factors  are  specially  structured  matrix  entities  having  control  information  in  the 
diagonal  terms.  They  may  only  be  reliably  used  by  the  back-substitution  module  gfbs. 

Design  Requirements: 

1.  DECOMP  can  process  both  real  and  complex  machine-precision  matrices. 

2.  The  back-substitution  phase  of  equation  solving  is  performed  with  module  GEBS. 

3.  The  triangular  factors  [L]  and  [0]  may  not  be  used  reliably  by  matrix  utilities  other  than  GFBS. 
Error  Conditions: 

None 
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Large  Matrix  Utility  Module:  FBS 
Entry  Point:  FBS 


Purpose: 

lb  perform  the  forward/backward  substitution  phase  of  equation  solving  for  symmetric  matrices  that 
have  been  decomposed  with  module  sdccmp. 

MAPOL  Calling  Sequence: 

CALL  FBS  {[L] ,  [RHS],  [RHS] ,  ISIGN); 

Application  Calling  Sequence: 

CALL  FBSS  (L,  RHS,  ANS,  ISIGN,  IKOR,  RKOR,  DKOR) 

[L]  The  lower  triangular  decomposition  factor  obtained  from  sdccmp 

(Input,  Character) 

[RHS]  The  matrix  of  right-hand  sides  of  the  equations  being  solved 

(Input,  Character) 

[RHS]  The  matrix  of  resulting  solutions  of  the  equations  (Output,  Character) 

ISIGN  Sign  of  the  right-hand  sides  in  [RHS]  (+1  for  positive,  -1  for  negative  ) 

(Input,  Integer) 

ikor  ,  rkor  ,  DKOR  The  base  address  of  the  open  core  common  block  in  integer,  real  and  dou¬ 

ble  precision  arrays,  respectively  (Input) 

Method: 

Given  a  real  symmetric  system  of  equations 
[K]  [X]  *  ±[P] 

the  sdcomp  large  matrix  utility  is  used  to  compute 

[K]  *  [L]  [D]  [L]t 

such  that  [D]  is  a  diagonal  matrix.  This  module  then  completes  the  solution  for  [X]  as 

[L]  [Y]  -  ±[P] 

[L]TtX]  «  [D]'1  [Y] 

If  [RHS]  is  blank,  the  inverse  of  the  decomposed  matrix  will  be  returned  in  [ANS] . 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Large  Matrix  Utility  Module:  GFBS 

Entry  Point:  GFBS 

Purpose: 

Tb  perform  the  forward/backward  substitution  phase  of  equation  solving  for  general  matrices  that  have 
been  decomposed  with  module  DKCCMP. 

MAPOL  Calling  Sequence: 

CALL  GFBS  (  [L]  ,  [0]  ,  [RHS]  ,  [ANS],  ISIQ*)  ; 

Application  Calling  Sequence: 

CALL  GFBS  (L,  0,  RHS,  ANS,  ISIGN,  IKOR,  RKOR,  DKOR) 

[L] ,  [0]  The  names  of  the  lower  and  upper  triangular  decomposition  factors  from 

decgmp  (Input,  Character) 

[RHS]  The  matrix  of  right-hand  sides  of  the  equation  being  solved 

(Input,  Character) 

[ans]  The  matrix  of  resulting  solutions  of  the  equations  (Output,  Character) 

ISIGN  Sign  of  the  right-hand  sides  in  [ANS]  (Input, +1  for  positive,  -1  for  nega¬ 

tive)  (Input,  Integer) 

IKOR,  rkor,  dkor  The  base  address  of  the  open  core  common  block  in  integer,  real  and  dou¬ 

ble  precision  arrays,  respectively  (Input) 

Method: 

Given  a  general,  real,  or  complex  system  of  equations 
[K]  [X]  =  ±[P] 

the  decoisp  large  matrix  utility  is  used  to  compute 

[K]  =  [L][U] 

This  module  then  completes  the  solution  for  [X]  as: 

[L]  [Y]  *  ±[P] 

[U][X]  =  [Y] 

If  [RHS]  is  blank,  the  inverse  of  the  decomposed  matrix  will  be  returned  in  [ANS] . 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Large  Matrix  Utility  Module:  MERGE 
Entry  Point:  MXMERG 


Purpose: 

lb  merge  four  submatrices  into  a  single  matrix  [A]  based  on  one  or  two  partitioning  vectors. 

Z  !  £  ]  -  « 

MAPQL  Calling  Sequence: 

CALL  MERGE  ([A],  [All!  ,  [A21]  ,  [A12]  ,  [A22] ,  [CP],  [RP]  >  ; 

Application  Calling  Sequence: 

CALL  MXMERG  (A,  All,  A21,  A12 ,  A22 ,  CP,  RP,  KORB) 

[A]  The  resulting  merged  matrix  (Output,  Character) 

[Ai  j  ]  The  input  partitions  as  shown  above  (Input,  Character) 

[RP]  The  row  partitioning  vector  (Input,  Character) 

[CP]  The  column  partitioning  vector  (Input,  Character) 

sore  Open  core  base  address  (Input) 

Method: 

The  partitioning  vectors  [CP]  and  [RP]  must  be  column  vectors  containing  zero  and  nonzero  terms. 
The  [All]  partition  will  be  placed  in  [A]  at  positions  where  both  [RP]  and  [CP]  are  zero.  The  [A12] 
partition  will  be  placed  in  [A]  at  positions  where  [RP]  is  nonzero  and  [CP]  is  zero.  The  other  partitions 
are  treated  in  a  similar  manner. 

If  some  of  the  partitions  are  null,  they  may  be  omitted  from  the  MAPOL  calling  sequence  or  a  character 
blank  may  be  used  in  the  application  calling  sequence.  In  a  similar  manner,  if  the  row  and  column 
partition  vectors  are  the  same,  one  of  them  may  be  omitted  or  left  blank  in  the  MAPOL  call.  They  must 
both  be  present  in  the  application  call. 

If  a  row  or  column  merge  alone  is  required  in  the  MAPOL  sequence,  the  special  purpose  MAPOL  utilities 
rohmerge  and  COIMERGE  may  be  used. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Large  Matrix  Utility  Module:  MPYAD 

Entry  Point:  MPYAD 

Purpose: 

lb  perform  the  general  matrix  multiply  and  add  operations  as  shown  below: 

(1)  CD]  -  ±[A]  [B]±[C]  or  =±[A][B] 

(2)  [D]  *  ±[A]T[B]±[C]  or  =  ±[A]T[B] 


MAPOL  Calling  Sequence: 

None,  the  MAPOL  syntax  supports  algebraic  matrix  operations  directly 
CD]  :*  ±[A]*[B]  +CC]; 

[D]  :»  ±TRANS([A])*[B]±[C]  ; 


Application  Calling  Sequence: 

CALL  MPXAD  (A,  B,  C,  D,  TFLAG,  SIGNAB,  SIGNC,  IKOR,  RKOR,  DKOR) 


A 

B 

C 

D 


The  name  of  the  input  A  matrix  (Character) 

The  name  of  the  input  B  matrix  (Character) 

The  name  of  the  input  C  matrix  or  blank  (Character) 
The  name  of  the  output  D  matrix  (Character) 


TFLAG 


SIGNAB 


SIGNC 


IKOR, RKOR, 
DKOR 


The  transpose  flag 

*  o  no  transpose 

=*  1  transpose  matrix  A 
(Integer,  Input) 

The  sign  on  the  [A]  CB]  product 

*  +1  +  [A]  [BJ 

-  -1  -[AJ  CB] 

(Integer,  Input) 

The  sign  on  the  EC]  matrix 
»  +1  +CC] 

*  0  no  CC]  matrix 

-  -1  -[C] 

(Integer,  Input) 

The  base  address  of  the  open  core  common  block  as  integer,  real  and  dou¬ 
ble  precision  arrays  (Input) 


Method: 

If  no  CC]  matrix  exists,  the  c  argument  should  be  blank  and  the  signc  argument  should  be  zero. 
Design  Requirements: 

None 


Error  Conditions: 
None 
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Large  Matrix  Utility  Module:  MXADD 

Entry  Point:  MXADD 

Purpose: 

‘lb  perform  the  general  matrix  addition  as  shown  below: 
tc]  «  a  [A]  +  p[B] 

MAPOL  Calling  Sequence: 

None,  the  MAPOL  syntax  supports  algebraic  matrix  operations  directly. 
[C]  :»  (a)  [A]  ±  (P)  [B] 

Application  Calling  Sequence: 


CALL  MXADD 

(A,  B,  C,  ALPHA,  BETA,  DKOR,  ZKOR) 

A 

The  name  of  the  input  A  matrix  (Character) 

B 

The  name  of  the  input  B  matrix  (Character) 

C 

The  name  of  the  output  C  matrix  (Character) 

ALPHA 

The  constant  complex  multiplier  of  matrix  A.  Real  array  of  length  2,  the 
first  word  is  the  real  part  of  the  constant,  the  second  is  the  imaginary 
part.  (Input, Complex) 

BETA 

As  alpha  for  the  B  matrix.  (Input, Complex) 

DKOR , IKOR 

The  base  address  of  open  core  common  block  as  double  precision  and  inte¬ 
ger,  respectively  (Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 


Large  Matrix  Utility  Module:  PARTN 
Entry  Point:  MXPRTN 


Purpose: 

Tb  partition  a  matrix  [A]  into  four  submatrices  based  on  one  or  two  partitioning  vectors: 
[A] 


All  I  A12 
A21  I  A22 


MAPOL  Calling  Sequence: 

CALL  PARTN  ([A],  [All],  [A21] ,  [A12] ,  [A22J ,  [CP],  [RP] ) ; 


Application  Calling  Sequence: 

CALL  MXPRTN  (A,  All,  A21,  A12 ,  A22 ,  CP,  RP,  RORE) 

[A]  The  matrix  to  be  partitioned  (Input,  Character) 

[Ai  j  ]  The  resulting  partitions  as  shown  above  (Output,  Character) 

[RP]  The  row  partitioning  vector  (Input,  Character) 

[CP]  The  column  partitioning  vector  (Input,  Character) 

kore  The  base  address  of  the  open  core  common  block  (Input,  Integer) 

Remarks: 

The  partitioning  vectors  [CP]  and  [RP]  must  be  column  vectors  containing  zero  and  nonzero  terms. 
The  [All]  partition  will  be  formed  from  [A]  at  positions  where  both  [RP]  and  [CP]  are  zero.  The 
[A12]  partition  will  be  formed  from  [A]  at  positions  where  [RP]  is  nonzero  and  [CP]  is  zero.  The  other 
partitions  are  treated  in  a  similar  manner. 

If  some  of  the  partitions  are  not  desired  as  output,  they  may  be  omitted  from  the  MAPOL  calling  sequence 
or  a  character  blank  may  be  used  in  the  application  calling  sequence.  In  a  similar  manner,  if  the  row 
and  column  partition  vectors  are  the  same,  one  of  them  may  be  omitted  or  left  blank  in  the  MAPOL  call. 
They  must  both  be  present  in  the  application  call. 

If  a  simple  row  or  column  partition  is  required  in  the  MAPOL  sequence,  the  special  purpose  MAPOL 
utilities  RQWPART  and  COLPART  may  be  used. 

Design  Requirements: 

None 


Error  Conditions: 
None 
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Large  Matrix  Utility  Module:  RE  IG 

Entry  Point:  REIG 

Purpose: 

Tb  solve  the  equation: 

C  [K]  -  X[M]  Hu)  =0 


for  its  eigenvalues,  A,  and  their  associated  eigenvectors  {o}. 

MAPOL  Calling  Sequence: 

CALL  REIG  (ITER,  BCID,  USET(BCID)  ,  [K]  ,  [M]  ,  [MR],  [EM] ,  LAMA,  [PHI],  [MI]  ,  NPHI) ; 


Application  Calling  Sequence: 


CALL  REIG  (ITER,  BCID,  USET,  K,  M,  MR,  1»I,  LAMA,  PHI,  MI,  OEIGS,  RKOR,  DKOR) 


ITER 

BCID 

USET 


The  design  iteration  number  (Integer,  Input) 

The  boundary  condition  identification  number  (Integer,  Input) 

The  entity  defining  structural  sets  for  the  current  boundary  condition 


[K] ,  [M] 
[MR] 
[DM] 
LAMA 

[PHI] 

[MI] 


The  stiffness  and  mass  matrices  (Input,  Character) 

The  rigid  body  mass  matrix  (Input,  Character) 

The  rigid  body  transformation  matrix  (Input,  Character) 

A  relational  entity  containing  a  list  of  extracted  eigenvalues 
(Output,  Character) 

A  matrix  whose  columns  are  the  eigenvectors  corresponding  to  the  ex¬ 
tracted  eigenvalues  (Output,  Character) 

The  modal  mass  matrix  (Output,  Character) 


NPHI 
OEIGS 
RKOR, DKOR 


The  number  of  eigenvectors  computed  (Integer,  Output) 

The  name  of  the  output  entity  for  statistical  information  (Character) 

The  open  core  common  base  address  for  real  and  double  precision  arrays, 
respectively  (Input) 


Method: 

The  matrices  [K]  and  [M]  must  be  real  and  the  reduced  mass  matrix  [MR]  and  the  rigid  body 
transformation  matrix  [DM]  are  not  required.  The  REIG  module  must  query  tire  CASE  relational  entity 
to  determine  which  set  of  EIGR  eigenvalue  extraction  data  to  use.  Because  of  the  multidisciplinary 
nature  of  the  code,  REIG  assumes  that,  if  called,  an  eigenanalysis  is  required.  It  uses  the  EIGR  data  that 
correspond  to  the  selection  for  the  current  boundary  condition,  BCID. 

Design  Requirements: 

None 


Error  Conditions: 
None 
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Large  Matrix  Utility  Module:  ROWMERGE 

Entry  Point:  MXMERG 

Purpose: 

lb  merge  two  submatrices  into  a  single  matrix  [A]  row-wise: 

w  -  [£  ] 

MAPOL  Calling  Sequence: 

CALL  ROKMERSE  (  [A]  ,  All]  ,  [A21]  ,  [RP]  )  ; 


Application  Calling  Sequence: 

CALL  MXMERG  (A,  All,  A21,  BLANK,  BLANK,  BLANK,  RP,  KORE) 


[A] 

[All] , [A21] 
tBP] 

BLANK 

KORE 


The  resulting  merged  matrix  (Output,  Character) 

The  input  partitions  as  shown  above  (Input,  Character) 

The  row  partitioning  vector  (Input,  Character) 

A  character  blank  (Input,  Character) 

The  base  address  of  the  open  core  common  block  (Input,  Integer) 


Method: 

The  partitioning  vector  [RP]  must  be  a  column  vector  containing  zero  and  nonzero  terms.  The  [All] 
partition  will  be  placed  in  [A]  at  positions  where  [RP]  is  zero.  If  either  of  the  partitions  [All]  or  [A12] 
is  null,  it  may  be  omitted  from  the  MAPOL  calling  sequence  or  a  blank  may  be  used  in  the  application 
calling  sequence. 

The  rowpart  large  matrix  utility  module  performs  the  inverce  of  this  module. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Large  Matrix  Utility  Module:  ROWPART 
Entry  Point:  MXPRTN 


Purpose: 

lb  partition  a  matrix  [A]  into  two  submatrices  row-wise: 


MAPOL  Calling  Sequence: 

CALL  ROWPART  {  [A]  ,  [All]  ,  [A21]  ,  [RP]  )  ; 

Application  Calling  Sequence: 

CALX.  MXPRTN  {A,  All,  A21,  BLANK,  BLANK,  BLANK,  RP,  KQRE) 

[A]  The  matrix  being  partitioned  (Input,  Character) 

[Aij  ]  The  resulting  partitions  shown  above  (Output,  Character) 

[RP]  The  partitioning  vector  (Input,  Character) 

BLANK  A  character  blank  (Input,  Character) 

KORE  The  base  address  of  the  open  core  common  block  (Input,  Integer) 

Method: 

The  partitioning  vector  [RP]  must  be  a  column  vector  containing  zero  and  nonzero  terms.  The  [All] 
partition  will  then  contain  those  columns  of  [A]  corresponding  to  a  zero  value  in  [RP] .  If  either  partition 
is  not  desired  as  output,  it  may  be  omitted  from  the  MAPOL  calling  sequence  or  a  BLANK  may  be  used 
in  the  application  calling  sequence. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Large  Matrix  Utility  Module;  SDCGM? 
Entry  Point:  SDCCMP 


Purpose: 

lb  decompose  a  symmetric  square  matrix  [A]  into  the  form: 

[A]  -4  [L]  [D]  [L]T 

where  [L]  is  a  lower  triangular  factor  and  the  diagonal  matrix  and  [D]  has  been  stored  on  the  diagonal 
of  [L]. 

MAPOL  Calling  Sequence: 

CALL  SDCGMP  (  [A]  ,  [LJ  ,  OSET(BC)  ,  SETNAM)  ; 

Application  Calling  Sequence: 

CALL  SDCOMP  (A,  L,  CHLSKY ,  USET,  SEXNAM,  IKOR,  RKOR,  DKOR) 

[A]  The  matrix  to  be  decomposed  (Input) 

[L]  The  lower  triangular  factor  (Output) 

CHLSKY  The  input  selection  of  Cholesky  decomposition 

*  0  no  Choleeky 

*  1  use  Cholesky 
(Integer) 

USET  The  entity  defining  structural  sets  for  the  current  boundary  condition 

SETSffiH  The  current  structural  set  name 

ikor  ,  rkor  ,  dkor  The  base  address  of  the  open  core  common  block  in  integer,  real  and  dou¬ 

ble  precision  arrays,  respectively  (Input) 

Method: 

The  SDCOMP  module  can  decompose  real  and  complex  symmetric  matrices.  The  resultant  lower  factor, 
[L] ,  is  a  specially  structured  matrix  entity  having  the  terms  of  [D]  on  the  diagonals.  It  may,  therefore, 
only  be  reliably  used  by  the  back-substitution  module,  FBS. 

Design  Requirements: 

None 

Error  Conditions: 

1.  Matrix  A  is  singular. 
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Large  Matrix  Utility  Module:  TRNSPOSE 

Entry  Point:  TRNSPZ 

Purpose: 

lb  generate  the  transpose  of  a  matrix. 

[A]  -*  [a]t 

MAPOL  Callin  ?  Sequence: 

CALL  TRNSPOSE  { [A] ,  [ATRANS] ) ; 

Application  Calling  Sequence: 

CALL  TKNSFZ  (A,  ATRANS,  IXOR,  DXOR) 

[A]  The  name  of  the  input  matrix  to  be  transposed  (Input,  Character) 

[ATRANS]  The  name  of  the  resulting  transposed  matrix  (Output,  Character) 

IKOR/DXOR  The  base  address  of  the  open  core  common  block  in  integer  and  double 

precision,  respectively.  (Input) 

Method: 

The  output  matrix  entity,  [atrans]  ,  must  already  exist  on  the  database.  It  will  be  flushed  and  loaded 
by  the  transpose  utility.  All  matrix  types  and  precisions  are  supported.  As  a  special  feature,  the  user 
controlled  11th  through  20th  words  of  the  INPO  array  for  the  input  matrix  are  copied  onto  the  transposed 
matrix. 

Design  Requirements: 

1.  Tiie  spill  logic  for  the  utility  has  a  limit  of  eight  scratch  files  to  perform  the  transpose.  If  the  transpose 
cannot  be  performed  in  eight  passes  using  the  available  memory,  the  utility  will  terminate. 

Error  Conditions: 

None 
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8.  THE  CADDB  APPLICATION  INTERFAC 


The  Computer  Automated  Design  Database  (CADDB)  is  the  heart  of  the  ASTROS  software 
system.  It  has  been  designed  to  provide  the  structures  and  access  features  typically  required  for  scientific 
software  applications  development.  CADDB  can  be  viewed  as  a  set  of  data  entities  that  are  accessible  by 
a  suite  of  utility  routines  called  the  application  interface  as  shown  below: 


There  are  three  types  of  entities:  Unstrunim-ed,  Relational,  and  Matrix.  These  are  described 
individually  in  the  following  paragraphs. 

Unstructured  Entities. 

Unstructured  entities  form  the  least  organized  data  type  that  may  be  used.  An  unstructured 
entity  may  be  considered  as  a  set  of  variable  length  records  which  have  no  predetermined  structure  and 
which  may  or  may  not  have  any  relationship  with  each  other.  This  is  illustrated  by  the  following: 
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Unstructured  entities  are  typically  used  when  "scratch"  space  is  needed  in  an  essentially  sequen¬ 
tial  manner.  Two  important  points,  however,  are  that  each  record  may  be  accessed  randomly  if  the  entity 
is  created  with  an  index  structure,  and  that  records  may  be  read  or  written  either  in  their  entirety  or  only 
partially.  Details  of  these  features  are  discussed  in  Subsection  8.6. 

Relational  Entities. 

Relational  entities  are  very  highly  structured  tables  of  data.  The  rows  of  the  table  are  called 
entries  or  tuples  and  the  columns  are  called  attributes,  as  shown  below: 


DATABASE 


ATTRIBUTES 


GID 

X 

Y 

z 

101 

Q.O 

0.0 

0.0 

102 

1.0 

0.0 

0.0 

103 

1.0 

1.0 

0.0 

104 

O 

o 

1.0 

o 

o 

ENTRIES 
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The  definition  of  the  attributes  and  their  types  is  called  the  schema  of  the  relation.  Because  the 
schema  is  an  inherent  part  of  a  relation’s  data  structure,  each  attribute  may  be  referred  to  by  its  name.  In 
addition,  because  each  of  the  attributes  is  independent  of  the  others,  it  is  possible  to  retrieve  or  modify 
only  selected  attributes  by  performing;  a  projection  of  the  relation.  Attributes  may  also  be  defined  with 
keys.  If  an  attribute  is  keyed,  an  index  structure  is  built  that  allows  rapid  direct  access  to  a  given  entry. 
There  is  a  restriction,  however,  that  a  keyed  attribute  must  have  unique  values  for  all  entries. 

Another  powerful  feature  is  the  ability  to  retrieve  entries  that  have  been  qualified  by  one  or  more 
conditions.  A  condition  is  a  constraint  definition  for  an  attribute  value.  For  instance,  in  the  example 
above,  the  condition  of  X=1.0  might  be  specified  prior  to  data  retrieval.  Only  those  entries  that  satisfy  the 
given  constraint  or  constraints  are  then  returned. 


Relational  entities  are  used  when  the  data  they  contain  will  be  accessed  or  modified  on  a  selective 
basis.  This  eliminates  the  need  to  move  large  sequential  sets  of  data  back-and-forth  when  modifying  or 
retrieving  only  small  amounts  of  data.  An  additional  feature  available  with  CADDB  is  the  "blast"  access 
of  a  relation.  This  allows  the  data  to  be  treated  sequentially  while  maintaining  the  relational  form,  these 
and  other  features  are  fully  described  in  Section  8.5. 

Matrix. Entities^ 


One  of  the  most  important  data  structures  encountered  in  engineering  applications  is  the  matrix. 
Matrix  algebra  forms  the  basis  for  the  finite  element  method  employed  by  ASTROS.  The  efficient  per¬ 
formance  of  this  algebra,  along  with  additional  operations  such  as  simultaneous  equation  solvers,  eigen- 
solvers  and  integration  schemes,  is  critical  to  such  a  software  system.  CADDB  represents  matrices  in 
packed  format.  This  format  has  been  used  extensively  by  the  NASTRAN  system  for  the  last  30  years 
with  excellent  success.  The  representation  of  a  matrix  on  CADDB  is  shown  below: 


DATABASE 


1 

ROW 

n 

•  •  » 

ROW 

n 

•  •  • 

ESi 

2 

ROW 

n 

•  •  • 

l 

3 

ROW 

n 

mm 

END 

4 

ROW 

n 

Sfi 

ROW 

n 

•  •  • 

BE3B 

5 

ROW 

n 

•  •  • 

-V  '■  "V”' 

Referring  to  the  figure,  note  that  only  the  non-null  columns  of  a  matrix  are  stored,  thus  reducing 
disk  space  utilization.  Within  each  column  are  one  or  more  strings.  A  string  is  a  sequential  burst  of  data 
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entities  with  a  header  that  indicates  the  first  row  position  of  the  data  in  the  given  column  and  "n",  the 
number  of  terms  in  the  string,  this  representation  allows  a  further  data  compression  in  that  zero  terms  in 
the  column  are  not  physically  stored. 

A  complete  library  of  matrix  utilities  is  available  within  the  ASTROS  system.  These  utilities  are 
coded  to  use  to  use  the  packed  format  to  its  best  advantage.  All  matrix  data  should  be  stored  in  this 
manner.  Many  access  methods  are  available  for  matrix  entities.  A  matrix  may  be  positioned  randomly  to 
a  given  column,  an  entire  column  may  be  read  or  written,  individual  terms  may  be  read  or  written  and  so 
on.  These  functions  are  described  in  Subsection  8.4. 
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8.1 .  CADDB  BASIC  DESIGN  CONCEPTS 


The  CADDB  implementation  was  influenced  by  three  fundamental  design  goals:  Open-endedness, 
performance,  and  structured  programming  methodology.  The  basic  internal  design  of  the  database  im¬ 
poses  no  unrealistic  restrictions,  a  virtually  unlimited  number  of  different  databases  and  entities  can  be 
processed  simultaneously  as  long  as  there  is  memory  to  hold  the  required  information.  The  only  fixed 
restrictions  are  those  imposed  by  the  computer  hardware  and  not  the  design.  For  example,  the  maximum 
number  of  blocks  in  the  entire  database  is  281  and  the  maximum  number  of  words  in  each  entity  is  also 
231.  This  restriction  follows  from  the  32-bit  word  length  of  some  of  the  target  machines. 

The  performance  goals  of  the  database  had  to  address  both  I/O  and  CPU  issues.  The  optimization 
of  I/O  performance  is  usually  in  direct  conflict  with  minimal  memory  utilization.  When  faced  with  an  I/O 
versus  memory  conflict,  reduced  I/O  was  generally  selected.  Summarized  in  the  following  are  typical 
design  decisions  impacted  by  this  issue: 

1.  All  bit  maps  required  by  the  database  are  kept  in  memory  to  reduce  I/O  requirements  of  free 
block  management. 

2.  Directory  pointers  for  all  entities,  open  or  closed,  are  kept  in  memory  to  reduce  directory  search 
time. 

3.  While  any  type  of  entity  is  open,  all  schema  definition  data  are  kept  in  memory. 

CADDB  was  designed  in  top-down  structured  manner.  It  is  divided  into  functional  modules  that 
simplify  implementation,  testing,  and  maintenance.  Generically,  the  functions  of  these  modules  are: 

1.  ENTITY  CODE:  Separate  groups  of  routines  are  provided  for  each  of  the  three  entity  types. 

2.  RELATIVE  BLOCK:  These  routines  process  the  block  allocation  tables  to  convert  relative  block 
numbers  used  by  entity  routines  into  physical  blocks. 

3.  BUFFER  MANAGEMENT:  All  buffer  management  is  done  by  these  routines. 

4.  FREE  BLOCK  MANAGEMENT:  The  allocating  and  freeing  or  physical  blocks  is  performed  here. 

5.  INDEX  PROCESSING:  All  index  processing  is  done  by  these  routines.  Two  sets  of  routines,  one 
for  sequential  indices  and  one  for  binary  indices,  are  provided. 

6.  DIRECTORY:  A  separate  set  of  routine  is  provided  to  do  all  directory  processing. 

7.  MEMORY  MANAGEMENT:  All  memory  management  is  provided  by  these  routines. 

This  highly  modular  design  provides  several  advantages.  The  most  important  is  that  new  features  can  be 
added  with  a  minimal  effect  on  the  existing  code.  For  example,  a  double  buffering  scheme  could  be  added 
to  reduce  I/O  wait  time  by  simply  modifying  the  buffer  management  routines. 
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8.1.1.  Physical  Structure 


Each  physical  database  is  comprised  of  a  set  of  disk  files.  An  index  file  and  at  least  one  data  file 
are  required  for  each  database.  The  index  file  contains  the  necessary  control  information  to  find  entities 
on  the  database.  This  information  includes  the  following: 

1.  DIRECTORY:  Contains  information  required  to  process  each  entity. 

2.  FBBM:  The  Free  Block  Bit  Maps  (FBBM)  are  used  to  keep  track  of  the  blocks  which  are  allocated 
and  free. 

3.  BAT:  The  Block  Allocation  Table  (BAT)  is  used  to  keep  track  of  the  physical  blocks  used  by  each 
entity. 

4.  SCHEMA:  The  SCHEMA  defines  the  attribute  structure  for  each  relational  entity. 

5.  INDEX:  Each  matrix  or  unstructured  entity  can  have  optional  indexes  built  to  allow  quick  access 
to  any  column  or  record.  Relational  entities  can  also  have  indices  built  for  any  attribute. 

The  data  files  are  used  to  store  the  actual  information  in  each  entity.  Multiple  data  files  can  be  used  to 
split  the  database  over  several  physical  disk  drives.  Free  block  allocation  is  performed  in  a  cyclic  fashion 
among  the  data  files  to  balance  the  I/O  load  on  the  system. 

8.1.2.  improvements  Over  Other  Databases 

The  design  of  a  new  ASTROS  database  was  required  to  address  deficiencies  in  existing  available 
codes.  The  GINO  I/O  system  of  NASTRAN,  while  efficient,  is  a  file  management  system,  not  a  database. 
Separate  files  are  required  for  each  entity  and  only  matrix  and  unstructured  entities  are  supported,  the 
RIM  database,  developed  by  the  IPAD  program  for  NASA,  supports  the  relational  entity  type  but  does  not 
adequately  support  either  unstructured  or  matrix  types.  Additionally,  the  RIM  system  suffers  from  severe 
restrictions  and  performance  penalties.  The  following  summarize  the  functional  improvements  that  make 
CADDB  superior  to  these  existing  systems: 

1.  The  three  entity  types  have  been  combined  into  one  database  in  as  consistent  a  manner  as 
possible. 

2.  The  dynamic  memory  manager  (See  Subsection  8.3)  allows  the  database  to  be  open-ended 
without  overburdening  an  application  code  which  also  makes  large  demands  on  memory. 

3.  Multiple  databases  and  as  many  entities  as  memory  allows  may  be  processed  simultaneously. 

4.  Multiple  jobs  can  have  READONLY  access  to  the  same  database.  With  CADDB,  a  system 
database,  as  described  in  Chapter  3.2,  is  provided.  This  database  contains  data  required  by  each 
ASTROS  job. 

5.  An  improvement  over  GENO  allows  existing  records  or  columns  of  unstructured  and  matrix 
entities  to  be  rewritten  without  destroying  any  other  data  in  the  entity. 

6.  "Garbage-collection"  of  freed  blocks  is  handled  automatically  by  the  database.  The  dump  and 
restore  requirement  of  some  databases,  such  as  REM,  is  eliminated. 
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7.  The  concept  of  projections  has  been  added  to  all  relational  entity  access  calls.  This  allows 
application  codes  to  process  only  those  attributes  needed  for  each  entry  of  the  relation.  This 
allows  a  new  attribute  to  be  added  to  a  relation  without  impacting  previously  coded  modules 
not  requiring  the  new  attribute. 

8.1.3.  Memory  Requirements 

As  discussed  in  the  introduction  to  this  section,  trade-offs  in  design  between  memory  and  I/O 
performance  were  generally  made  in  favor  of  I/O.  In  this  subsection,  the  general  memory  requirements  of 
CADDB  are  summarized.  The  equations  below  use  the  following  symbols: 

I  the  index  block  file  size  in  words 
D  the  data  file  block  size  in  words 

E  the  number  of  entities  on  all  open  databases 

P  the  number  of  physical  files  in  the  database 

N  the  number  of  attributes  for  a  relation 

The  following  memory  is  required: 

1.  For  the  entity  name  table:  Mi  =  10E 

2.  For  each  open  database:  M2  =  21  +  6P  +  I(P+1) 

3.  For  each  open  entity  without  indexing:  Ms  ~  40  +  D  +  I 

4.  For  each  open  entity  with  indexing:  M<$  =  40  +  D  +  31 

5.  For  each  relation,  and  additional  requirement  is:  Ms  =  49N 

Using  an  .ndex  file  block  size  of  256  words  and  a  data  file  block  size  of  2,048  words,  these 
relations  indicate  that,  for  a  typical  engineering  module,  the  memory  requirement  would  be  approxi¬ 
mately  4,000  words  greater  than  that  required  by  the  NASTRAN  GINO  system. 

This  is  felt  to  be  a  small  trade-off  for  the  significant  capability  enrichment. 
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8.2.  THE  GENERAL  UTILITIES 


4 


There  are  nine  general  CADDB  utility  routines  as  shown  below: 


SUBROUTINE 

FUNCTION 

DBCREA 

Creates  a  database  entity 

DBOPEN 

Opens  a  database  entity  prior  to  I/O 

DBREMA 

Renames  a  database  entity 

DBEQUV 

Equivalences  two  entity  names 

DBSWCH 

Interchanges  the  names  of  two  entities 

DBDEST 

Destroys,  or  removes,  an  entity  and  all  of  its  data  from  the  database 

DBFLSH 

Removes  the  data  contents  of  an  entity 

DBCLOS 

Tfermi nates  I/O  for  an  entity 

DBEXXS 

Checks  for  existence  of  an  entity 

DBNEMP 

Checks  for  existence  of  data  in  an  entity 

General  Utilities  are  those  which  apply  to  any  entity  type.  Two  additional  general  data  utilities  are 
DBINIT  and  dbtefm.  These  are  system  level  modules  and  are  presented  in  Chapter  4. 

Creatine  a  New  Entity, 

To  create  a  new  database  entity,  the  routine  dbcrea  is  used.  This  utility  enters  the  new  entity 
name  and  its  type  into  the  database  directory.  Although  there  are  three  entity  classes,  there  are  two 
options  for  both  matrix  and  unstructured  entities,  indexed  or  unindexed.  Typical  calls  to  create  the  three 
entities  pictured  in  Subsection  8.1  could  be: 


CALL 

DBCREA 

('GRID'  , 

'REL'  ) 

CALL 

DBCREA 

('  STUF'  , 

' IUN' ) 

CALL 

DBCREA 

( '  MATX' , 

'MAT'  ) 

The  ASTROS  executive  system  automatically  creates  all  database  entities  that  are  declared  in 
the  MAPOL  program.  An  application  programmer  usually  creates  only  scratch  entities  within  a  given 
module. 

Accessing  Entities. 

Prior  to  adding  new  data,  modifying  existing  data  or  accessing  old  data  for  an  entity,  the  entity 
must  be  opened,  and  when  I/O  is  completed  it  must  be  closed.  This  is  none  to  allow  optional  use  of 
memory  resources  as  discussed  in  Subsection  8.1.  Using  the  examples  as  before,  I/O  is  initiated  by  the 
calls: 


CALL 

DEOPEN 

('GRID'  , 

INFO,  'R/W', 

' FLUSH' , 

ISTAT) 

CALL 

DBOPEN 

('STUFF' 

,  INFO,  'RO', 

'NOFLUSH' 

,  ISTAT) 

CALL 

DBOPEN 

('MAXT' , 

INFO,  'R/W', 

' FLUSH' , 

ISTAT) 

The  array  INFO  is  very  important.  It  contains  20  words  that  provide  information  about  the  data 
contents  of  the  entity,  such  as  the  number  of  attributes  and  entries  in  a  relation,  the  number  of  records  in 
an  unstructured  entity  and  the  number  of  columns  in  a  matrix.  The  first  10  words  of  INFO  are  used  by 
the  database.  The  programmer  may  use  the  second  20  words  for  any  purpose  desired.  The  info  array  «s 


then  updated  when  the  entity  is  closed.  As  an  option,  access  to  an  entity  may  request  that  the  data 
contents  of  the  entity  be  destroyed,  or  FLUSHed,  when  opening  it. 

When  all  activity  is  completed  for  a  given  entity,  it  must  be  closed  to  free  memory  used  for  I/O. 
This  is  done  with  a  call  such  as: 

|  CALL  DBCLOS  ('GRID')  ~  1 
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Database  General  Utility  Module:  DBCLOS 

Entry  Point:  DBCLOS 

Purpose: 

Tb  terminate  I/O  from  a  specified  database  entity. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBCLOS  (  ENTNAM  ) 

entnam  The  name  of  the  entity  (Character,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  General  Utility  Module:  DBCREA 

Entry  Point:  DBCREA 

Purpose: 

T"  create  a  new  data  entity. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBCREA  <  ENTNAM,  TXPE  ) 

entnah  The  name  of  the  entity  (Character,  Input) 

TYPE  The  entity  type  (Character,  Input) 


'REL' 

Relation 

'MAT' 

Matrix 

'IMAT' 

Indexed  matrix 

'ON' 

Unstructured 

'  IUN' 

Indexed  unstructured 

Method: 

None 

Design  Requirements: 
None 

Error  Conditions: 
None 
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Database  General  Utility  Module:  DBDEST  % 

Entry  Point:  DBDEST 

Purpose: 

Tb  destroy  a  database  entity,  removing  all  data  from  the  database  files  and  the  entity  name  from  the 
list  of  entities. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBDEST  (  ENTNAM  ) 

ENTNAM  The  name  of  the  entity  (Character,  Input) 

Method: 

None 

Design  Requirements: 

1.  ENTNAM  may  not  be  open. 

Error  Conditions: 

None 
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Database  General  Utility  Module:  DBEQUV 

Entry  Point:  DBEQUV 

Purpose: 

Tb  equivalence  two  entity  names  to  point  to  the  same  data.  After  a  DBEQUV  operation,  the  two  names 
are  synonymous.  The  only  way  to  break  an  established  equivalence  is  to  destroy  one  of  the  entities  which 
destroys  the  equivalences  along  with  the  entity  and  its  data. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBEQUV  (  NAME1,  NAME 2  ) 

NAME1  Name  of  currently  existing  entity  (Character,  Input) 

NAME2  Name  to  be  made  equivalent  to  NAME1  (Character,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  General  Utility  Module:  DBEXIS 

Entry  Point:  DBEXIS 

Purpose: 

lb  determine  if  a  given  entity  already  exists  on  the  database. 
MAPOL  Calling  Sequence: 

None 


Application  Calling  Sequence: 

CALL  DBEXIS  (  ENTNAM,  EXIST,  I TYPE  ) 


ENTNAM 

EXIST 


I  TYPE 


Method: 

None 

Design  Requirements: 
None 

Error  Conditions: 
None 


The  name  of  the  entity  (Character,  Input) 

Status  of  the  entity  (Integer,  Output) 

0  does  not  exist 

1  exists 

The  entity  type  (Integer,  Output) 
o  undefined  entity 

1  relation 

2  matrix 

3  indexed  matrix 

4  unstructured 

5  indexed  unstructured 
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Database  General  Utility  Module:  DBFLSH 

Entry  Point:  DBFLSH 

Purpose: 

lb  delete,  or  flush  all  of  the  data  from  a  database  entity.  The  entity  itself  remains  in  existence,  but  is 
empty. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBFLSH  (  ENTNAK  ) 

entnam  The  name  of  the  entity  (Character,  Input) 

Method: 

None 

Design  Requirements: 

1.  ENTNAM  may  not  open. 

Error  Conditions: 

None 
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Database  General  Utility  Module:  DBNEMP 

Entry  Point:  DBNEMP 

Purpose: 

Tb  return  a  logical  TRUE  or  FALSE  depending  on  whether  an  entity  has  entries,  records  or  columns 
(TRUE)  or  if  it  is  nonexistent  or  empty  (FALSE). 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

DBNEMP  (  ENTNAM  ) 

sara»M  The  name  of  the  entity  (Character,  Input) 

Method: 

DBNEMP  is  a  LOGICAL  FUNCTION  that  returns  TRUE  if  and  only  if  the  named  EOTNM4  exists  and 
contains  entries  if  relational,  columns  if  matrix  or  records  if  unstructured.  Any  other  condition  returns 
a  FALSE. 

Design  Requirements: 

1.  ENTNAM  may  not  open. 

Error  Conditions: 

None 
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Database  General  Utility  Module:  DBOPEN 

Entry  Point:  DBOPEN 

Purpose: 

lb  open  a  database  entity  foi  subsequent  I/O  operations. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBOPEN  <  ENTNAM,  INFO,  RW,  FLUSH,  IS TAT  ) 

entnam  The  name  of  the  entity  (Character,  Input) 

info  Array  of  length  20  words  containing  entity  information  (Integer,  Output) 


INFO 

RELATION 

MATRIX 

UNSTRUCTURED 

1 

TYPE 

TYPE 

TYPE 

2 

NATTR 

NCOL 

NREC 

3 

NENTRY 

NROW 

MAX  REC  LEN 

in  words 

4 

— 

PREC 

— 

5 

— 

DEN*1000 

— 

6 

— 

FORM 

— 

7 

~ 

Maximum  number  of 
nonzero  terms  in  any  column 

— 

8 

— 

Maximum  number  of  strings 
in  column 

— 

9 

- 

Maximum  length  of  a  string 

— 

10 

- 

— 

— 

Type  Codes  (TYPE)  are: 

1 

REL 

2 

MAT 

3 

IMAT 

4 

UN 

5 

IUN 

Form  Codes  (FORM)  are: 

1 

rectangular 

2 

symmetric 

3 

diagonal 

4 

identity 

5 

square 
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Precision  Codes  (PREC)  are: 

1 

real,  single-precision 

2 

real,  double-precision 

3 

complex,  single-precision 

4 

complex,  double-precision 

rw  Type  of  access  (Character,  Input) 

'  r/W'  Read/Write  access 

'  ro'  Read  only  access 

flush  Flush  option  (Character,  Input) 

*  FLUSH'  flush  entity  on  open 

'  noflush  '  do  not  flush  entity  on  open 

istat  Return  status  (Integer,  Output) 

0  entity  opened 

101  entity  does  not  exist 


Method: 

None 

Design  Requirements: 

1.  The  INFO  array  is  loaded  on  the  call  to  DBOPEN  and  not  subsequently  modified.  The  programmer 
may  use  the  second  10  words  for  any  purpose.  DBCLOS  will  write  the  current  info  data  to  the 
database. 

2.  Multiple  open  entities  must  not  share  INFO  array  locations.  Care  must  be  taken  not  to  modify  the 
first  10  words  within  the  application. 

Error  Conditions: 

None 
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Database  General  Utility  Module:  DBRENA 

Entry  Point:  DBRENA 

Purpose: 

lb  rename  a  database  entity. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBRENA  (  OLDHAM,  NEWHAM  ) 

OLDNAM  Existing  entity  name  (Character,  Input) 

newnam  New  entity  name  (Character,  Input) 

Method: 

None 

Design  Requirements: 

1.  The  entity  may  be  open. 

Error  Conditions: 


None 


Database  General  Utility  Module:  DBSWCH 
Entry  Point:  DBSWCH 


i 


Purpose: 

'lb  switch  the  names  of  two  database  entities. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  DBSWCH  (  ENTNAM  ) 

HAME1  Name  of  first  entity  (Character,  Input) 

NAME2  Name  of  second  entity  (Character,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 

( 


( 
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®  8.3.  THE  DYNAMIC  MEMORY  MANAGER  UTILITIES 

The  dynamic  memory  manager  (DMM)  is  a  group  of  utility  routines  that  allow  the  applications 
programmer  to  work  with  open-ended  arrays  in  memory.  This  is  important  for  two  reasons.  The  first  is 
that  memory  is  not  wasted  by  fixed  length  FORTRAN  arrays.  The  second  reason  is  to  allow  algorithms  to 
use  spill-logic.  Spill-logic  is  code  that  can  perform  operations  on  only  that  portion  of  the  required  data 
that  fits  in  memory  at  a  given  time.  Free  memory,  (that  beyond  the  fixed  code  and  data  areas)  may  be 
organized  into  any  number  of  blocks,  and  groups  of  blocks,  as  shown  below: 


ALLOCATED  REGION  SIZE 


This  dynamic  memory  area  can  be  viewed  as  a  type  of  virtual  memory  those  paging  is  under  control  of  the 
programmer.  Static  memory  languages,  such  as  FORTRAN,  are  very  inefficient  users  of  memory.  The 
DMM  can  eliminate  some  of  this  inefficiency.  As  an  example,  consider  a  routine  to  perform  the  matrix 
addition 


[A]  +  [B]  =  [C] 
defined  by  the  equations 

Cij  =  Aij  +  Bjj 
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Three  possible  implementations  are  shown,  all  based  on  the  assumption  that  the  available  mem¬ 
ory,  after  all  other  components  of  the  program  are  loaded,  is  30,000  words. 

The  Classical  FORTRAN  Approach. 

The  classical  brute-force  FORTRAN  solution  to  this  problem  is  to  see  that  3  arrays  each  dimen¬ 
sions  100  by  100  will  fit  perfectly  in  the  available  memory.  The  routire  i?  duly  coded  as: 

DIMENSI0N  A  (100,  100),  B  (100,  100),  C  (100,  loO) 

c 

C  ASSUME  THE  MATRICES  ARE  ALL  N*M 
C 

DO  200  1=1,  N 

DO  100  J=l,  M 

C  { I ,  J)  =  A(I,  J)  +  B  (I,  J) 

100  CONTINUE 

200  CONTINUE 


With  this  algorithm,  the  matrix  sizes  are  fixed  at  100  by  100.  If  the  matrices  are  only  3  by  3,  99 
plus  percent  of  the  memory  is  wasted.  Further,  although  a  20  by  600  matrix  would  occupy  the  same 
10,000  words,  it  cannot  fit  into  the  predefined  array.  This  latter  problem  can  easily  be  fixed  by  storing  the 
matrix  in  a  singly  dimensioned  array  of  10,000,  which  already  implies  the  programmer  must  manage  the 
array. 


By  using  the  dynamic  memory  manager  both  problems  shown  in  the  last  section  disappear. 
Consider  the  code  segment: 


COMMON/MEMORY/  Z  (1) 

C 

C  ALLOCATE  MEMORY  FOR  EACH  MATRIX 


CALL 

MMBASE 

(  Z  ) 

CALL 

MMGETB 

(  'AMAT', 

' RSP' , 

N*M, 

'MAXT' , 

IA, 

ISTAT 

) 

CALL 

MMGETB 

(  '  BMAT' , 

' RSP' , 

N*M, 

'MAXT' f 

IB, 

ISTAT 

) 

CALL 

MMGETB 

(  'CMAT', 

'RSP'  , 

N*M, 

'MAXT' , 

IC, 

ISTAT 

) 

DO  100  1=1,  N*M 
II  =  I  -  1 

Z  (  IC  +  II  )  =  Z  (  IA  +  II  )  +  Z  (  IB  +  II  ) 
100  CONTINUE 


This  code  allows  all  30,000  words  of  memory  to  be  used  regardless  of  the  shape  of  the  matrices.  Addition¬ 
ally,  it  uses  exactly  the  memory  required  if  the  operation  is  smaller  than  the  available  memory. 
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Spill-logic  can  be  implemented  in  a  number  of  ways  using  the  matrix  utilities  described  in 
Subsection  8.4.  When  spill-logic  is  used,  only  those  portions  of  the  matrices  involved  in  an  operation  are 
brought  into  memory.  Operations  are  then  performed  and  intermediate  or  final  results  stored  on  the 
database.  With  this  coding  technique,  problems  of  virtually  unlimited  size  may  be  addressed.  There  are 
nine  DMM  utilities  that  may  be  used  hy  an  application  programmer.  Each  routine  is  prefixed  with  the 
letters  MM.  A  summary  of  these  routines  is  shown  below. 


SUBROUTINE 

FUNCTION 

MMBASE 

KMBASC 

Used  by  each  module  to  define  the  location  of  the  memory  base  address 

MMDUMP 

Prints  a  table  of  allocated  memory  blocks 

M  1 

Frees  allocated  memory  by  individual  blocks  or  by  groups  of  blocks 

MMFREO 

MMGETB 

Gets  a  block  of  memory  of  the  specified  type  and  length 

MHREDU 

Reduces  the  size  of  a  block 

HMSQUZ 

Compresses  memory  I/O  areas 

MMSTAT 

Returns  the  maximum  contiguous  memory  that  is  available  to  the  module 

Database  Memory  Manager  Utility  Module:  MMBASC 

Entry  Point:  MMBASC 

Purpose: 

Tb  define  the  base  address  of  dynamic  memory  that  contains  character  data. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MMBASC  (  ARAY ,  LEM  ) 

afay  The  name  of  a  character  army  from  which  memory  pointers  will  be  meas¬ 

ured 

len  The  length  of  the  character  string  elements  in  ARAY 

Method: 

None 

Design  Requirements: 

1.  Only  one  call  to  m*basc  may  be  made  in  a  module. 

Error  Conditions: 

None 


i 


5 


i 
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NoneDatabase  Memory  Manager  Utility  Module:  MMBASE 

Entry  Point:  MMBASE 

Purpose: 

lb  define  the  base  address  of  dynamic  memory  of  reference  to  an  array. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MMBASE  (  ARAY  ) 

ARAY  The  name  of  an  array  from  which  memory  pointers  will  be  measured 

Method: 

None 

Design  Requirements: 

1.  This  routine  must  be  the  first  called  in  each  moduie  that  uses  the  memory  manager. 

2.  It  cannot  be  used  for  memory  containing  character  data  (see  mmbasc). 

Error  Conditions: 

None 
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Database  Memory  Manager  Utility  Module:  MMDUMP 

Entry  Point:  MMDUMP 

Purpose: 

lb  print  a  formatted  table  of  allocated  memory  blocks  to  the  output  file. 

MAPOL  Calling  Sequence: 

None 

Applicatit  n  Calling  Sequence: 

CALL  MMDUMP 

Method: 

None 

Design  Requirements: 

1.  The  utility  assumes  the  MM1N1T  has  been  called  to  initialize  the  open  core  memory  block. 

2.  In  some  cases  of  corrupted  memory,  the  use  of  this  routine  may  result  in  an  infinite  loop. 
Error  Conditions: 

None 
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Database  Memory  Manager  Utility  Module:  MMFREE 

Entry  Point:  MMFREE 

Purpose: 

lb  free  a  memory  block  for  subsequent  use. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MMFREE  (  BLK  ) 

blk  Name  of  block  to  be  freed  (Character,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Memory  Manager  Utility  Module:  MMFREG 

Entry  Point:  MMFREG 

Purpose: 

To 

MAPQL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MMFREG  (  GRP  ) 

grp  Name  of  the  group  of  blocks  to  be  freed  (Character,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Memory  Manager  Utility  Module:  MMGETB 


Entry  Point:  MMGETB 
Purpose: 

Tb  allocate  a  block  of  dynamic  memory. 
MAPQL  Calling  Sequence: 

None 


Application  Calling  Sequence: 

CALL  MMGETB  (  BK,  TYPE,  LEN,  GRP,  IPNT,  ISTAT  ) 

blk  The  name  assigned  to  this  memory  block 

If  the  block  name  is  blank,  the  block  is  a  special  unnamed  memory  block 
in  that  it  can  only  be  freed  with  a  mmfreg  call  and  mmredu  calls  are  not 
allowed  for  the  block.  (Character,  Input) 

type  The  data  type  of  the  memory  block:  (Character,  Input) 


LEN 


GRP 


IPNT 


ISTAT 


Method: 

None 


'  rsp'  real,  single-precision  or  integer 

'  RDP'  real,  double-precision 

'  CSP'  complex,  single-precision 

'  CDP'  complex,  double-precision 

'  char'  character 

Length  of  block  measured  in  the  units  of  TYPE  (Integer,  Input) 

Name  defining  a  group  to  which  this  block  belongs  (Character,  Input) 

Pointer  to  the  allocated  block  of  memory  referenced  to  the  base  location 

(Integer,  Output) 

Status  return 

0  memory  successfully  allocated 

101  insufficient  memory  available 


Design  Requirements: 
None 


Error  Conditions: 

1.  Attempt  to  allocate  a  memory  block  of  zero  length. 

2.  Attempt  to  allocate  a  duplicate  block/group  name. 
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Database  Memory  Manager  Utility  Module:  MMREDU 

Entry  Point:  MMREDU 

Purpose: 

Tib  reduce  the  size  of  a  memory  block  that  is  larger  than  needed. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 


CALI.  MMREDO 

(  BLK,  TYPE,  LENGTH  ) 

BLB t 

The  name  assigned  to  this  memory  block  (Character,  Input) 

TYPE- 

The  data  type  of  the  memory  block:  (Character,  Input) 

'  RSP' 

real,  single-precision  or  integer 

'  RDP' 

real,  double-precision 

'CSP' 

complex,  single-precision 

'  CDP' 

complex,  double-precision 

'CHAR' 

character 

LENGTH 

Length  to 

be  freed  measured  in  units  of  type  (Integer,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

1.  Attempt  to  reduce  memory  block  to  zero  length. 
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Database  Memory  Manager  Utility  Module:  MMSQUZ 
Entry  Point:  MMSQUZ 


Purpose: 

Tb  squeeze,  or  compress,  any  unused  I/O  buffer  space  used  by  the  database. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  M4SQUZ 

Method: 

None 

Design  Requirements: 

1.  This  routine  should  not  be  used  within  an  application  routine,  it  is  an  executive  memory  manage¬ 
ment  function. 

Error  Conditions: 

None 
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Database  Memory  Manager  Utility  Module:  MMSTAT 

Entry  Point:  MMSTAT 

Purpose: 

Tb  determine  the  maximum  number  of  contiguous  single-precision  words  available  for  dynamic  alloca¬ 
tion. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MMSTST  (  C0H7IG  ) 

contig  The  maximum  number  of  contiguous  single-precision  words  available  (In¬ 

teger,  Output) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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8.4.  UTILITIES  FOR  MATRIX  ENTITIES 


The  matrix  entity  utilities  are  designed  to  provide  a  number  of  different  methods  for  accessing 
complete  columns,  portions  of  columns,  or  single  terms  of  a  matrix.  The  use  of  these  various  methods 
depends  on  the  source  of  data  defining  the  matrix  and  the  intensity  of  the  computational  algorithm.  The 
routines  available  are: 


SUBROUTINE 

FUNCTION 

_ 

MXINIT 

Initializes  a  matrix  entity  for  I/O 

MXFOKM 

Change  the  form  of  a  matrix 

MXPOS 

Positions  to  a  specified  matrix  column 

MXRPOS 

MXNPOS 

MXSTAT 

Gets  matrix  column  information 

MXPAK 

Packs  a  column  of  a  matrix 

MXUNP 

Unpacks  a  column  of  a  matrix 

MXPKTI 

Packs  a  column  of  a  matrix  either  term-by-term  or  by  partial 
column 

MXPKT 

MXJPKTM 

MXPKTF 

MXUPTI 

Unpacks  a  column  of  a  matrix  either  term-by-term  or  by  partial 
column 

MXUPT 

MXUPTM 

MXUPTF 

8.4.1,  Creating  a  Matrix. 

After  a  matrix  entity  has  been  created  it  must  be  initialized  before  it  can  be  used.  The  MXINIT 
call  provides  information  required  for  the  storing  of  data  into  the  matrix.  For  example,  to  create  and 
initialize  a  matrix  entity  for  a  real,  single-precision,  symmetric  matrix  with  1,000  rows  the  following  code 
is  required: 


INTEGER  INFO 

(20) 

CALL  DBCREA 

( '  KGG'  , 

'MAT'  ) 

CALL  DBOPEN 

( '  KGG'  , 

INFO, '  R/W' ,  'FLUSH',  7STAT) 

CALL  MXINIT 

( '  KGG' , 

1000,  ' RSP' ,  'SYM') 

Whenever  a  matrix  is  flushed,  with  either  a  dbopen  or  a  dbflsh  call,  the  initialization  data  are 
cleared.  Therefore,  an  MXINIT  call  is  required  before  reusing  the  matrix  in  this  case.  Similarly,  if  a 
matrix  entity  is  going  to  be  redefined,  it  must  be  flushed  before  a  new  MXINIT  call  may  be  made. 
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8.4.2.  Packing  and  Unpacking  a  Matrix  by  Columns. 


The  simplest  method  to  process  a  matrix  is  with  the  full  column  routines  MXPAK  and  MJCONP.  Each 
of  these  routines  may  process  either  a  full  column  or  a  portion  of  a  column.  In  either  case,  only  one  call  is 
allowed  for  each  column.  The  subsequent  call  will  process  the  next  column.  The  following  code  illustrates 
the  packing  and  unpacking  of  matrix  by  columns: 


c 

c 

PACK  MATRIX  BY  COLUMNS 

c 

DO  100  ICOL  =  1,  NCOL 

CALL  MXPAK  ('KGG'  , 

COLDTA  (1, ICOL) ,1,1000) 

100 

CONTINUE 

c 

c 

UNPACK  MATRIX  BY  COLUMNS 

c 

CALL  MXPOS  {'KGG'  ,1) 

DO  200  ICOL  =  1,  NCOL 

CALL  MXUNI  ('KGG', 

DATA, 1,1000) 

200 

CONTINUE 

8.4.3.  Obtaining  Matrix  Column  Statistics. 

The  MXPAK  routine  removes  any  zero  terms  in  the  column  to  reduce  the  amount  of  disk  space 
required  to  store  the  matrix.  Consecutive  nonzero  terms  are  stored  in  strings.  Whenever  a  zero  term  is 
encountered,  the  current  string  is  terminated  and  e  new  string  is  started.  The  mxstat  routine  may  be 
used  to  obtain  statistics  about  each  column.  The  following  code  gives  an  example  of  how  this  information 
can  be  used  to  unpack  only  those  terms  between  the  first  and  last  nonzero  terms. 

DO  100  I CL  =  1,  NCOL 

CALL  MXSTAT  ( ' KGG' ,  COLID,  FNZ,  LNZ,  NZT,  DEN,  NSTR) 

CALL  MXUNP  ('KGG',  DATA,  FNZ,  LNZ-FNZ  +  1) 

100  CONTINUE 
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8.4.4.  Packing  and  Unpacking  a  Matrix  by  Terms. 


A  matrix  can  also  be  processed  by  individual  terms.  T.  ^ack  a  matrix  termwise  requires  a  series 
of  calls  for  each  column.  The  first  call  must  be  a  column  initialization  call,  followed  by  a  series  of  calls  to 
pack  single  terms  and,  finally,  a  column  termination  call.  The  following  code  shows  the  packing  of  an 
individual  matrix  column  by  terms: 

- 

C  INITIALIZE  TERM-WISE  PACKING 

C 

CALL  MXPKTI  ( ' KGG' ,  IKGG) 

C 

C  READ  MATRIX  TERM  AND  PACK 

C 

100  READ  (5,  *,  END=200)  I ROW,  VAL 

CALL  MXPKT  {IKGG,  VAL,  I ROW) 

GO  TO  100 
C 

C  TERMINATE  COLUMN 

C 

200  CALL  MXPKTF  ('KGG') 


Note  that  the  termwise  packing  must  be  done  in  ascending  row  order. 

A  similar  set  of  calls  is  required  to  unpack  a  matrix  by  terms.  The  MXSTAT  routine  is  used  to 
determine  the  number  of  nonzero  terms  that  exist  in  the  column.  The  following  code  will  unpack  and 
print  the  nonzero  terms  for  a  matrix  column 


C  DETERMINE  NUMBER  OF  TERMS 

C 

C 

CALL  MXSTAT  ('KGG',  COLID,  FNZ,  LNZ,  NZT,  DEN,  NSTR) 
C 

C  START  UNPACKING  THE  MATRIX  COLUMN 

C 

CALL  MXUPTI  ('KGG',  IKGG) 

DO  100  ITERM=1,  NZT 

CALL  MXUPT  (IKGG,  VAL,  IROW) 

WRITE  (6,*)  ' ROW=' ,  IROW,  ' TERM=' , VAL 
100  CONTINUE 

C 
C 
C 

_ CALL  MXUPTF  ('KGG') 


It  is  not  required  that  each  term  in  the  column  be  unpacked.  If  any  terms  are  left,  the  MXUPTF  routine 
will  ignore  them  and  position  the  matrix  to  the  next  column. 
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8.4.5.  Packing  and  Unpacking  a  Matrix  by  Strings. 


As  explained  earlier,  matrix  data  are  actually  stored  in  strings  of  terms  with  intervening  zero 
terms  compressed.  A  series  of  routines  is  provided  to  allow  matrices  to  be  accessed  by  strings.  The  use  of 
these  routines  is  similar  to  the  termwise  routines  in  that  there  is  a  column  initialization  call,  a  call  for 
each  string,  and  a  column  termination  call.  The  following  code  shows  the  packing  of  a  matrix  which 
contains  two  strings,  the  first  with  five  terms  and  the  second  with  three  terms. 


c 

c 

INITIALIZE  FOR  STRING  PACKING  1 

c 

CALL 

MXPKTI  ('KGG',  I KGG) 

c 

c 

PACK 

OUT  TWO  STRINGS 

c 

CALL 

MXPKTM  ( IKGG,  STR1,  10,  5) 

CALL 

MXPKTM  (IKGG,  STR2 ,  20,  3) 

c 

c 

TERMINATE  STRING  PACKING 

c 

CALL 

MXPKTF  ( ' KGG' ) 

Packing  a  column  by  strings  differs  in  several  respects  from  packing  by  columns.  First,  more  than 
one  MXPKTM  call  is  allowed  for  each  column.  With  MXPAK  only  one  call  per  column  is  allowed.  Secondly,  no 
compression  of  zero  terms  is  done  within  a  string.  This  feature  can  be  used  to  insure  that  certain  terms  of 
a  matrix  are  stored,  even  if  zero,  so  they  can  later  be  rewritten  randomly. 


The  unpacking  of  a  matrix  by  strings  is  shown  in  the  following  code  example.  Note  the  use  of  the 
MXSTAT  routine  to  determine  the  number  of  strings  stored  in  the  column. 


c 

c 

c 

c 

c 

c 


100 

c 

c 

c 


DETERMINE  THE  NUMBER  OF  STRINGS 

CALL  MXSTAT  ( '  KGG'  ,  COLID,  FNZ,  LNZ,  NZT,  DEN,  NSTR) 
UNPACK  COLUMN  BY  STRINGS 
CALL  MXPKTI  ('KGG',  I KGG) 

DO  100  1=1,  NSTR 

CALL  MXUPTM  ('KGG',  VALS,  IROW,  NROW) 

WRITE  (6,*)  'TERMS  FROM  ROW',  IROW,  'TO  ROW', 

*  I ROW +N ROW- 1 ,  'ARE',  (VALS  (I),  1=1, NROW) 

CONTINUE 

TERMINATE  COLUMN  UNPACKING 
CALL  MXUPTF  ( ' KGG'  ) 


It  is  important  that  MXSTAT  be  used  to  determine  the  number  of  strings  in  a  column  because, 
under  several  conditions,  the  number  may  be  different  from  the  number  of  strings  packed.  First,  if  the 
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string  packed  does  not  fit  in  the  current  buffer,  it  will  be  automatically  split  over  two  buffers.  Secondly,  if 
t  o  strings  are  packed  consecutively,  they  will  be  automatically  merged  into  one  string  in  the  buffer. 

8.4.6.  Matrix  Positioning. 


Several  routines  are  provided  to  position  a  matrix  randomly  to  a  given  column.  This  operation  can 
be  done  on  either  indexed,  IMAT,  or  unindexed  matrices,  but  the  presence  of  an  index  speeds  up  the 
processing  greatly.  The  following  code  shows  the  use  of  these  routines  to  randomly  read  three  matrix 
columns. 


c 

c 

POSITION  TO 

COLUMN  10  AND  UNPACK 

c 

CALL  MXPOS 

( ' KGG' ,  10) 

CALL  MXUNP 

{' KGG' ,  DATA,  1,  1000) 

c 

c 

POSITION  FORWARD  5  COLUMNS 

c 

CALL  MXRPOS 

('KGG',  +5) 

CALL  MXUNP 

('KGG',  DATA  ,  1,  1000) 

c 

c 

POSITION  TO 

NEXT  NONNULL  COLUMN 

c 

CALL  MXNPOS 

('KGG'  ,  ICOL) 

CALL  MXUNP 

('KGG',  DATA,  1,  1000) 

The  first  mxunp  retrieves  the  data  for  column  10  and  leaves  the  matrix  positioned  at  the  start  of 
column  11.  The  mxkpos  call  positions  the  matrix  forward  five  columns  to  column  16.  The  second  MXONP 
call  then  retrieves  the  data  for  column  16.  The  results  of  the  MXNPOS  call  depend  on  the  data  stored  in  the 
matrix.  If  column  17  has  nonzero  terms,  it  will  be  positioned  there.  If  column  17  is  null,  the  matrix  will  be 
positioned  there.  If  column  17  is  null,  the  matrix  will  be  positioned  forward  until  a  nonnull  column  is 
found.  Note  that  both  mxpos  and  mxnpos  require  that  the  column  to  which  the  matrix  is  positioned 
exists.  The  mxnpos,  utility  is  the  more  general  in  that  it  determines  the  next  column  that  exists.  Null 
matrix  columns  can  be  packed  in  two  ways.  The  following  code  gives  examples  which  are  quite  different 
in  that  the  first  example  creates  a  column  with  no  nonzero  terms  while  the  second  example  creates  a  null 
column  which  does  not  exist. 


C 

—  —  - 1 

C 

CREATE  A  COLUMN  OF  ZEROS  WITH  MXPAK 

C 

CALL  MXPAK 

('KGG',  0.0, 1,1) 

C 

C 

CREATE  NULL 

COLUMN 

C 

CALL  MXPKTI 

('KGG',  I  KGG) 

CALL  MXPKTF 

('KGG'  ) 
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S.4.7.  Missing  Matrix  Columns. 


I 

For  extremely  sparse  matrices  it  is  possible  to  pack  only  the  columns  which  contain  data.  This 
feature  can  greatly  reduce  disk  space  requirements  for  these  matrices  because  space  is  not  wasted  for 
column  headers  and  trailers.  It  also  simplifies  coding  because  it  is  not  required  to  pack  null  columns  The 
following  example  shows  the  packing  of  an  extremely  sparse  matrix  which  contains  only  two  items. 


C 

c 

PACK 

DIAGONAL  TERM 

IN  COLUMN  100 

c 

CALL 

MXPOS  {'KGG', 

100) 

CALL 

MXPAK  ('KGG', 

1.0,100,1) 

c 

c 

PACK 

DIAGONAL  TERM 

IN  COLUMN  500 

c 

CALL 

MXPOS  ('KGG', 

500) 

CALL 

MXPAK  ( ' KGG' , 

1.0,100,1) 

When  a  matrix  does  not  have  all  its  columns  stored,  care  must  be  used  when  unpacking  it.  Since 
the  routines  only  operate  on  columns  physically  stored  in  the  matrix  only  two  sets  of  calls  are  required  to 
unpack  the  matrix. 


The  following  code  example  shows  one  method  of  unpacking  this  matrix. 


C 

C 

UNPACK  TWO  MATRIX  COLUMNS 

DO  100  ICOL  =1,2 

CALL  MXSTAT  ('KGG',  COLID,  FNZ, 

LNZ, NZT, DEN, NSTR) 

WRITE  (6,*)  'DATA  FOR  COLUMN', 

COLID 

CALL  MXUNP  ('KGG',  DATA, 1,1000) 

100 

CONTINUE 

This  example  illustrates  a  disadvantage.  The  code  must  know  the  exact  number  of  columns  stored 
in  the  matrix.  There  is  no  method  provided  to  determine  this.  The  next  example  shows  how  mxnpos  can 
be  used  to  produce  a  code  sequence  that  will  work  no  matter  how  many  physical  columns  are  stored  in  the 
matrix. 


c 

c 

c 

ioo 


POSITION  TO  NEXT  COLUMN 

CALL  MXNPOS  ( ' KGG' , I COL) 

IF  (  ICOL.GT.O  )  THEN 

WRITE  (6,*)  'DATA  FOR  COL',  ICCL 
CALL  MXUNP  ('KGG',  DATA, 1,1000) 
GO  TO  100 
ENDIF 


The  mxpos  and  mxrpos  utilities  should  be  used  with  extreme  caution  if  the  matrix  does  net 
contain  all  physical  columns.  These  routines  work  on  actual  column  numbers  and  will  cause  fatal  errors  if 
the  column  does  not  exist.  For  example,  an  mxpos  to  column  200  will  cause  an  eiTor  because  the  columry 


is  not  stored  in  the  matrix.  If  the  matrix  is  positioned  at  column  100,  an  MXRPOS  of  +100  will  also  fail 
because  column  200  is  not  stored  in  the  matrix. 

8.4.8.  Repacking  a  Matrix. 


Once  a  matrix  has  been  packed,  it  is  possible  to  rewrite  certain  columns  of  the  matrix  without 
disturbing  the  data  stored  in  any  other  columns.  The  only  restriction  is  that  the  topology  ot  the  matrix 
terms  cannot  change.  For  example,  if  MXPAK  was  used  to  pack  the  column,  all  zero  terms  are  compressed. 
Since  these  terms  are  not  physically  stored  in  the  matrix,  they  cannot  at  a  later  time  be  replaced  by  a 
nonzero  term,  this  can  be  avoided  by  using  the  termwise  or  stringwise  calls,  which  perform  no  zero 
compression.  The  following  example  shows  the  packing  of  a  matrix  column  and  the  subsequent  repacking 
of  it. 


c 

c 

PACK 

COLUMN 

1  OF  MATRIX 

c 

CALL 

MXPOS 

('  KGG'  ,  1) 

CALL 

MXPKTI 

( '  KGG' ,  I KGG) 

CALL 

MXPKTM 

(I KGG,  STR,  10,10) 

CALL 

MXPKTF 

( ' KGG' ) 

c 

c 

READ 

COLUMN 

1  OF  MATRIX 

c 

CALL 

MXPOS 

('KGG'  ,  1) 

CALL 

MXPKTI 

('KGG',  I KGG) 

CALL 

MXPKTM 

(IKGG,  DATA, I ROW, NROW ) 

CALL 

MXPKTF 

( ' KGG' ) 

c 

c 

DOUBLE  EACH 

NUMBER  IN  THE  STRING 

c 

DO  100  1=1, 

NROW 

DATA  ( I ) =DATA  (I)  *  2.0  f 

100 

CONTINUE 

c 

c 

REPLACE  THE 

STRING 

c 

CALL 

MXPOS 

('KGG'  ,1) 

CALL 

MXPKTI 

{'KGG',  IKGG) 

CALL 

MXPKTM 

(IKGG,  DATA, I ROW, NROW) 

CALL 

MXPKTF 

('KGG'  ) 

All  the  matrix  pack  utility  calls,  i.e.,  column,  term  and  string,  may  be  used  to  repack  matrix 
columns. 
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Database  Matrix  Utility  Module:  MXFORM 

Entry  Point:  MXFORM 

Purpose: 

Tb  change  the  form  of  a  matrix  entity. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MXFORM  (  NAME ,  FORM  ) 

name  The  matrix  name  (Character,  Input) 

form  The  new  matrix  form  (Character,  Input) 


'REC' 

Rectangular 

'SXM' 

Symmetric 

' DIAS' 

Diagonal 

'INDENT' 

Identity 

'SQUARE' 

Square 

Method: 

None 

Design  Requirements: 

1.  mxiorm  may  be  called  any  time  after  the  creation  of  the  matrix. 
Error  Conditions: 

1.  Illegal  form  value;  error  mxformo  1. 
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Database  Matrix  Utility  Module:  MXINI T 

Entry  Point:  MXINIT 

Purpose: 

Tb  initialize  a  matrix  prior  to  writing  data. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MXINIT  (  MATNAM,  NROW,  PREC,  FORM  ) 


MATNAM 

NROW 

PREC 


FORM 


Name  of  matrix  (Character,  Input) 

Number  of  rows  (Integer,  Input) 

The  precision  of  the  matrix  (Character,  Input) 

'  RSP'  Real,  Single-precision 

'  RDP'  Real,  Double-precision 

'  CSP'  Complex,  Single-precision 

'  CDP'  Complex,  Double-precision 

Form  of  the  matrix  (Character,  Input) 


'  RBC' 

'  STM' 

' DIAG' 

' INDENT' 
' SQUARE' 


Rectangular 

Symmetric 

Diagonal 

Identity 

Square 


Method: 

None 

Design  Requirements: 
None 

Error  Conditions: 
None 
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Database  Matrix  Utility  Module:  MXNPOS 

Entry  Point:  MXNPOS 

Purpose: 

lb  position  a  matrix  to  the  next  nonnull  column. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MXNPOS  (  MATNSM,  ICOL  ) 

M&tnam  Neme  of  matrix  (Character,  Input) 

ICOL  Column  number  positioned  to  (Integer,  Output) 

Method: 

None 

Design  Requirements: 

1.  If  there  are  no  more  nonnull  columns  in  the  matrix,  ICOL  is  set  to  zero 
Error  Conditions: 

None 
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Database  Matrix  Utility  Module:  MXPAK 

Entry  Point:  MXPAK 

Purpose: 

Tb  pack  all ,  or  a  portion,  of  a  matrix  and  then  to  move  to  the  next  column. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MXNPOS  (  MATNAM,  AJ3AY,  ROW1,  NROW  ) 

matnam  Name  of  mstrix  to  be  packed  (Character,  Input) 

aray  Array  containing  data  to  be  packed  (Any  type,  Input) 

ROWl  First  row  position  in  column  (Integer,  Input) 

NROW  Number  of  rows  to  pack  (Integer,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Matrix  Utility  Module:  MXPKT 

Entry  Point:  MXPKT 

Purpose: 

lb  pack  a  column  of  a  matrix  one  term  at  a  time. 

MAPQL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

C ALL  MXPKT  {  UNITID,  VAL,  IROW  ) 

tJKXTie  Unit  identification  from  MXPKTI  call  (Integer,  Input) 

val  The  value  to  be  packed  (Any  type,  Input) 

IROW  The  row  position  of  the  term.  IRCW  must  be  positive  and  greater  than  the 

value  in  any  previous  MXPKT  call  for  the  current  column  (Integer,  Input) 

Method: 

Nono 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Matrix  Utility  Module:  mxpktf 

Entry  Point:  MXPKTF 
Purpose: 

Tb  terminate  the  termwise  or  partial  packing  of  a  matrix  column. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MXPKTF  {  MATNAM  ) 

matnam  Name  of  the  matrix  being  packed  (Character,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Matrix  Utility  Module:  MXPKTI 

Entry  Point:  MXPKTI 

Purpose: 

Tb  initialize  a  matrix  column  for  term-by-term  or  partial  packing. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MXPKTI  (  MATNAM,  ONITID  ) 

matnam  Name  of  the  matrix  to  be  packed  (Character,  Input) 

ONITID  Unit  identifier  (Integer,  Output) 

Method: 

None 

Design  Requirements: 

1.  A  matrix  may  be  packed  by  columns  using  MXPAK,  by  terms,  or  by  partial  columns,  but  not  by  any 
combination. 

Error  Conditions: 

None 


i 


i 


( 
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Database  Matrix  Utility  Module:  mxpktm 


Point:  MXPKTM 


Purpose: 


Tb  pack  a  column  of  a  matrix  using  partial  columns. 
MAPOL  Calling  Seauence: 


Enuimsl 


CALL  MXPKTM  (  ONITID,  VALARR,  ROW1 ,  NROW  ) 


ONITID 


VALARR 


Unit  identifier  from  MXPXTI  call  (Integer,  Input) 
Array  of  values  to  be  packed  (Any  type,  Input) 
Initial  row  position  of  VALARR  (Integer,  Input) 
Number  of  rows  to  be  packed  (Integer,  Input) 


Method: 


Design  Requirements: 

1.  ROWl  and  NROW  must  be  positive. 
Error  Conditions: 
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Database  Matrix  Utility  Module:  MXPOS 

Entry  Point:  MXPOS 

Purpose: 

lb  position  a  matrix  to  a  specified  column. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MXPOS  (  MATNAM,  COL  ) 

MATNAM  Name  of  the  matrix  (Character,  Input) 

COL  Column  number  (Input,  Integer) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 


364 


Database  Matrix  Utility  Module:  MXRPOS 

Entry  Point:  MXRPOS 

Purpose: 

lb  position  a  matrix  to  a  column  by  specifying  the  column  increment  relative  to  the  current  column. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MXPOS  (  MATNAM,  DELCOL  ) 

mathrm  Name  of  the  matrix  (Character,  Input) 

delcol  Column  number  increment  (Integer,  Input) 

Method: 

None 

Design  Requirements: 

1.  Positive  delcol  positions  forward,  negative  position  backward  from  current  column. 

Error  Conditions: 

None 
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Database  Matrix  Utility  Module:  MXSTAT 

Entry  Point:  MXSTAT 

Purpose: 

Tb  obtain  status  information  for  the  current  column. 

MAPQL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MXSTAT  (  MATNAM,  COLID,  FNZ ,  LNZ ,  NZT,  DEN,  NSTR  ) 

MATNAM 
COLID 
FNZ 
LNZ 
NZT 
DEN 
NSTR 

Method: 

None 

Design  Requirements: 

1.  Note  that  for  very  large  matrices,  DEN  is  a  single-precision  number  and  may  be  numerically  zero 
even  if  there  are  nonzero  terms  in  the  matrix. 

Error  Conditions: 

None 


Name  of  the  matrix  (Character,  Input) 

Current  column  number  (Integer,  Output) 

First  nonzero  row  in  columndnteger,  Output) 

Last  nonzero  row  in  column  (Integer,  Output) 

Number  of  nonzero  rows  in  column  (Integer,  Output) 

Column  density  (Real,  Output)  (den  is  a  decimal  fraction,  e.g.,  40%=.40) 
Number  of  strings  in  column  (Integer,  Output) 
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Database  Matrix  Utility  Module:  MXUNP 

Entry  Point:  MXUNP 

Purpose: 

lb  unpack  all,  or  a  portion,  of  a  matrix  column  and  then  to  move  to  the  next  column. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MXUNP  {  MATNAM,  ARRAY,  ROWi,  NROW  ) 

matnam  Name  of  the  matrix  (Character,  Input) 

array  An  ay  containing  data  to  be  unpacked  (Any  type,  Output) 

row!  First  row  position  in  column  (Integer,  Input) 

nrow  Number  of  rows  to  unpack  (Integer,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Matrix  Utility  Module:  MXUPT 

Entry  Point:  MXUPT 

Purpose: 

Tb  unpack  a  column  of  a  matrix  one  term  at  a  time. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  MXUPT  (  UNITID,  VAL,  IROW  > 

UNITID  Unit  identification  from  MXUPTI  call  (Integer,  Input) 

VAL  The  value  of  the  term  (Any  type,  Output) 

IROW  The  row  position  of  the  term  (Integer,  Output) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Matrix  Utility  Module:  MXUPTF 

Entry  Point:  MXUPTF 

Purpose: 

Tb  terminate  the  termwise  or  partial  unpacking  of  a  matrix  column. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  maPTF  (  MATNAM  ) 

MATSJffig  Name  of  the  matrix  being  unpacked  (Character,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Matrix  Utility  Module:  MXUPTI 

Entry  Point-  MXUPTI 

Purpose: 

lb  initialize  a  matrix  column  for  term-by-term  or  partial  unpacking. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CAUL  MXUPTI  (  MATNAM,  UNITID  ) 

matnam  Name  of  the  matrix  (Character,  Input) 

UNHID  Unit  identifier  (Integer,  Output) 

Method: 

None 

Design  Requirements: 

1.  A  matrix  may  be  unpacked  by  columns  using  MXOHP,  by  term,  or  by  partial  columns,  using  MXUPT 
and  MXOT'JM,  but  not  by  any  combination. 

Error  Conditions: 

None 


380 


Database  Matrix  Utility  Module:  MXUPTM 


Entry  Point:  MXUPTM 


Purpose: 

Tb  unpack  partial  columns  of  a  matrix. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  i  tWISID,  VALARR,  ROW1 ,  NROW  > 


UH2SXJ5 

VAL&RR 

ROSsl 

HROW 


Unit  identifier  from  MXOTTI  call  (Integer,  Input) 

Array  that  will  contain  the  unpacked  rows  (Any  type,  Output) 
Initial  row  position  being  unpacked  (Integer,  Output) 

Number  of  rows  being  unpacked  (Integer,  Output) 


Method: 

None 

Design  Requirements: 
None 

Error  Conditions: 
None 
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8.5.  UTILITIES  FOR  RELATIONAL  ENTITIES 


8 


Relational  database  entities  are  used  to  save  highly  structured  data  that  will  be  accessed  and 
modified  in  a  random  manner.  Utilities  to  operate  on  relations  are  summarized  below: 


SUBROUTINE 

FUNCTION 

RESCHM 

Defines  the  schema  of  a  relation 

RE  PRO  J 

Defines  the  projection  of  the  relation  prior  to  I/O  activity 

REQURX 

Queries  the  schema  of  a  relation 

REGET 

Gets,  or  fetches  ,  a  qualified  entry  from  a  relation 

REGETM 

REUPD 

Updates  the  current  entry  of  a  relation 

REUPDM 

READD 

Adds  a  new  entry  to  a  relation 

READDM 

REPOS 

Positions  a  relation  to  an  entry 

RECPOS 

Checks  for  existence  of  a  given  entry 

RECORD 

Defines  constraints  or  WHERE  conditions  for  the  relation 

RESETC 

REENDC 

RENULD 

Checks  if  an  attribute  has  a  null  value 

RENULI 

RENULR 

REHULS 

RECLRC 

Clears  conditions  defined  for  a  relation 

REGB 

Gets,  or  fetches,  all  of  the  qualified  entries  from  a  relation 

REG3M 

REAB 

Adds  a  group  of  entries  to  a  relation 

REARM 

RESORT 

Sorts  the  entries  of  a  relation 

8,5.1.  Examples  of  Relational  Entity  Utilities. 

This  subsection  provides  specific  examples  of  operating  with  relations.  Particular  attention  should 
be  given  the  use  of  double-precision  data  attributes.  Special  routines  are  provided  for  such  attributes 
when  used  by  themselves  or  when  “mixed"  with  other  data  types. 
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8.5.2.  Creating  a  Relation. 


A  relational  entity  has  both  a  name  and  a  schema.  The  schema  defines  the  attributes  of  a  relation 
and  their  data  types.  Therefore,  a  call  to  the  RSSCHM  routine  is  required  in  addition  to  a  dbcrea  call  in 
order  to  complete  the  creation  of  a  relational  entity.  For  example,  to  create  relation  grid  (shown  in  the 
introduction  to  Section  8),  the  following  code  is  required: 


c 

c 

DEFINE 

ATTRIBUTES  TYPES,  AND  LENGTHS 

c 

CHARACTER  *8 

GATTR  (4) 

CHARACTER  *8 

GTYPE  (4) 

INTEGER 

GLEN  (4) 

DATA  GATTR  / 

'GID',  'X',  7  Y7 ,  7Z7/ 

DATA  GTYPE  / 

7 KINT7 ,  'RSP7,  7 RSP7, 7 RSP7  / 

DATA  GLEN  /  0 

,0,0,0  / 

c 

c 

CREATE  A  RELATION  AND  SCHEMA  f 

c 

CALL  DBCREA  ( 

'GRID7  ,  7  REL7 )  j 

CALL  RESCHM  ( 

'GRID7,  4,  GATTR,  GTYPE,  GLEN  )  j 

The  schema  is  specified  by  attribute  name  and  data  type.  Various  data  types  are  available.  In  the 
example,  the  grid  ID,  gid,  is  called  a  keyed  integer  (KINT).  This  causes  an  index  structure  to  be  created 
that  will  allow  fast  direct  access  to  a  given  entry.  The  coordinate  values  x,  Y,  and  z  are  defined  as  real, 
single-precision  (rsp).  The  length  parameters  (GLEN)  are  only  used  for  character  attributes  and  for  arrays 
of  integers  or  real  numbers.  An  array  of  values  would  be  used  if  the  overall  data  organization  is  relational 
but  some  groups  of  values  are  only  used  on  an  all-or-nothing  basis. 

8.5.3.  Loading  Relational  Data. 

Once  a  relation  has  been  created  it  may  be  loaded  with  data.  There  are  two  modes  of  adding  data: 
one  entry  at  a  time,  or  a  blast'  add  wherein  the  entire  relation,  or  a  large  part  of  it,  has  be6n  accumu¬ 
lated  in  memory.  For  each  mode,  there  are  two  options,  one  when  none  of  the  attributes  are  real, 
double-precision,  and  a  second  if  one  or  more  attributes  are  real,  double-precision.  Using  the  relation 
GRID,  the  example  below  indicates  how  it  could  be  loaded  on  an  entry-by-entry  basis. 
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c 

c 

ALLOCATE  BUFFER  AREA  FOR  ENTRIES  AND  INFO 

c 

INTEGER  IBUF  (4),  INFO  (20) 

c 

c 

USE  EQUIVALENCES  TO  HANDLE  REAL  DATA 

c 

EQUIVALENCE  (IGID,  IBUF  (1)),  (X,  IBUF  (2) 

EQUIVALENCE  (y,  IBUF  (3)),  (Z,  IBUF  (4)  ) 

) 

c 

c 

DEFINE  THE  PROJECTION  AS  THE  FULL  RELATION 

c 

CHARAC-TFR  *8  PATTR  (4) 

DATA  PATTR  /  ' GID' ,  'X',  ' Y' ,  'Z '/ 

c 

c 

OPEN  THE  ENTITY  FOR  I/O 

c 

CALL  DBOPEN  ('GRID',  INFO,  ' R/W' ,  'FLUSH', 
CALL  REPROJ  ('GRID',  4,  PATTR) 

ISTAT) 

c 

c 

READ  AN  ENTRY  FROM  INPUT,  ADD  TO  RELATION 

c 

DO  100  1=1,  I END 

READ  (5,  101)  IGID,  X,Y,Z 

CALL  READD  {'GRID',  IBUF) 

100 

CONTINUE 

c 

c 

c 

CALL  DBCLOS  ('GRID') 

Space  must  first  be  allocated  to  contain  an  entire  entry  of  the  relation.  This  buffer  must  be  of  a 
specific  type  so  that  equivalences  must  be  used  if  the  attributes  are  of  mixed  data  types.  The  projection  of 
the  relation  must  be  defined  (via  reproj)  even  if  all  attributes  are  being  selected.  If  the  data  had  been 
stored  in  memory  first,  the  RERDDB  routine  could  have  been  used  to  "blast"  all  of  the  entries  into  the 
relation  with  a  single  call. 
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8.6.  Accessing  a  Relation. 


A  relation  is  accessed  by  a  set  of  four  routines:  REGET,  REGETM,  REGB,  and  REGEM.  Several  other 
routines  now  come  into  play.  The  first  are  REPOS  and  recpos.  These  routines  are  used  to  find  an  entry 
within  a  relation  whose  key  is  equal  to  a  specific  value.  The  second  is  the  group  of  routines  record, 
RESETC,  reendc,  and  reclfc.  These  allow  the  specification  of  more  complex  "where"  clauses  that  are 
used  to  qualify  an  entry  of  the  relation. 


As  an  example,  suppose  that  the  X,  Y,  and  Z  coordinates  are  to  be  retrieved  for  a  grid  point  whose 
GID  is  1.  The  code  segment  below  could  be  used  to  perform  this: 


c 

c 

c 

c 

c 

c 


c 

c 

c 


c 

c 

c 

c 

c 

c 


ALLOCATE  BUFFER  -  ALL  OUTPUT  IS  REAL 

DIMENSION  COORDS  (3),  INFO  (20) 

DEFINE  THE  PROJECTION 

CHARACTER  +8  PATTR  (3) 

DATA  PATTR  /  'X',  '  Y' ,  '  Z'  / 

OPEN  THE  ENTITY  FOR  I/O 

CALL  DBOPEN  ('GRID',  INFO,  ' R/W' ,  ' NOFLUSH' ,  ISTAT) 
CALL  REPROJ  ('GRID',  3,  PATTR) 

POSITION  TO  THE  DESIRED  ENTRY 

CALL  REPOS  ('GRID',  'GID',  1) 

GET  THE  ENTRY 

CALL  REGET  ('GRID',  COORDS,  ISTAT) 


Note  that  GID  must  be  a  keyed  attribute  to  use  repos. 

To  qualify  an  entry  by  more  than  one  attribute,  a  sequence  of  an  RECORD  call,  any  number  of 
RESETC  calls,  and  an  reendc  call  can  be  used.  For  instance,  to  find  any  or  all  grid  points  whose 
coordinates  are  20=1,  Y=2,  Z=3,  the  code  segment  below  could  be  used: 

CALL  RECOND  ('GRID',  'X',  ' EQ' ,  1.0) 

CALL  RESETC  ('AND',  ' Y' ,  ' EQ' ,  2.0) 

CALL  RESETC  ('AND',  '  Z' ,  ' EQ' ,  3.0) 

CALL  REENDC 

CALL  REGET  ('GRID',  BUF,  ISTAT) 


Each  call  to  REGET  will  retrieve  an  entry  that  satisfies  the  specified  conditions.  An  ISTAT  value 
greater  than  zero  indicates  the  end  of  successful  retrievals.  Conditions  may  include  any  of  the  relational 
operators,  the  MAX  and  MIN  selectors  and  the  Boolean  operators  AND  and  OR.  If  one  of  either  min  or  MAX 
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issued,  however,  it  is  the  only  condition  allowed.  To  reset  a  new  set  of  conditions  on  an  open  relational 
entity,  the  utility  RECLRC  may  be  called  to  destroy  the  current  conditions. 

8.8.1.  Updating  a  Relational  entry. 

One  of  the  most  powerful  features  of  the  relational  database  is  the  ability  to  randomly  modify  a 
small  number  of  data  items  efficiently.  To  do  this,  the  utilities  redupd  and  REODPM  are  used.  The  update 
prr  .edure  is  a  simple  one.  First,  the  projection  is  set.  This  is  followed  by  positioning  to  a  row  or  rows  by 
specifying  a  REPOS,  recpos  or  an  recond.  Routine  REGET  is  then  used  to  fetch  the  entry.  One  or  more  of 
attributes  may  then  be  modified  in  the  buffer  and  an  RED  up  used  to  accomplish  the  update.  Note  that 
attributes  not  in  the  projection,  and  attributes  not  modified  in  the  buffer,  will  remain  unchanged. 

8.6.2.  Other  Operations. 

If  it  is  necessary  for  an  application  to  determine  the  schema  of  a  given  relation,  this  may  be  done 
with  the  utility  KEQURY.  This  routine  returns  the  names  and  types  of  each  attribute  in  the  schema. 
Finally,  a  relation  may  be  sorted  in  an  ascending  or  descending  manner  on  one  or  more  of  its  attributes 
by  using  the  utility  RESORT. 
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Database  Relational  Utility  Module:  REAB 

Entry  Point:  REAB 

Purpose: 

Tb  add  multiple  entries,  held  in  memory,  to  a  specified  relation. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  RFAB  (  RELNAK,  BOF,  IKOM  ) 

relnam  Name  of  the  relation  (Character,  Input) 

BOT  Array  that  contains  the  entries  to  be  added  to  the  relation  (Any,  Input) 

inum  The  number  of  entries  to  be  added  (Integer,  Input) 

Method: 

None 

Design  Requirements: 

1.  Only  integer,  real  single-precision,  or  string  attributes  may  be  added  with  this  routine. 

Error  Conditions: 

None 
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Database  Relational  Utility  Module:  REABM 
Entry  Point:  REABM 


Purpose: 


Tb  add  multiple  entries,  held  in  memory,  to  a  specified  relation  where  the  relational  attributes  are 
double-precision,  or  mixed  precision,  types. 

MAPOL  Calling  Sequence: 

None 


Application  Calling  Sequence: 

CALI.  REABM  (  RELNAM,  SHGL,  DBLE,  I  HUM  ) 


REWAM 

3NGL 

DBLE 

INCH 


Name  of  the  relation  (Character,  Input) 

Array  that  contains  the  single-precision  (Integer,  Real,  Single-Precision, 
or  String)  attributes  to  be  added  (Any,  Input) 

Array  that  contains  the  double-precision  attributes  to  be  added 
(Double,  Input) 

The  number  of  entries  to  be  added  (Integer,  Input) 


Method: 

None 

Design  Requirements: 
None 

Error  Conditions: 
None 
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Database  Relational  Utility  Module:  READD 
Entry  Point:  READD 


Purpose: 

To  add  a  new  entry  to  a  relation. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  READD  (  RELNAM,  BUF  ) 

relnam  Name  of  the  relation  (Character,  Input) 

BUS1  Array  that  contains  the  entries  to  be  added  to  the  relation  (Any,  Input) 

Method: 

None 

Design  Requirements: 

1.  Only  integer,  single-precision,  or  string  attributes  may  be  added  with  this  routine. 

Error  Conditions: 

None 
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Database  Relational  Utility  Module:  READDM 
Entry  Point:  READDM 


Tb  add  a  new  entry  to  a  relation  that  contains  double-precision,  or  mixed  precision,  attributes. 
MAPOL  Calling  Sequence: 


plication  Catling  Sequence: 

CALX.  READMM  {  BELNBM,  SNGL,  DBLE  ) 


Method: 

None 


Name  of  the  relation  (Character,  Input) 

Array  that  contains  the  single-precision  entry  data  (Any,  Input) 
Array  that  contains  the  double-precision  entry  data  (Double,  Input) 


Error  Conditions: 
None 
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Database  Relational  Utility  Module:  RECLRC 

Entry  Point:  RECLRC 

Purpose: 

lb  clear  the  conditions  set  on  a  relational  entity  without  performing  a  DBCLOS. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  RECLRC  (  ENTNflM  ) 

entnam  The  name  of  the  relational  entity  (Character,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Relational  Utility  Module:  RECOND 
Entry  Point:  RECOND 


Purpose: 

Tb  define  a  condition,  or  constraint,  for  a  relational  attribute  prior  to  performing  a  get  operation  (see 
also  RESETC). 

MAPQL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  RECOND  (  RELNAM,  ATTRNAM,  RE LOP,  VAL  ) 

REiiiAM  N ame  of  the  relation  (Character,  Input) 

ATTRNAM  Name  of  the  attribute  (Character,  Input) 

RELOP  The  relational  operator  for  the  constraint;  one  of '  EQ' ,  'NE' , '  GT' , '  LT' , 

'  SE' , '  LE' , '  MAX' , '  MIN'  (Character,  Input) 

VAL  The  value  to  be  tested  (Any,  Input) 

Method: 

None 

Design  Requirements: 

1.  VAL  must  be  the  same  type  as  the  ATTRNAM.  All  RELOPs  are  legal  for  attributes  of  type  '  INT' , 
'  KINT' , '  RSP' ,  and  '  RDP' .  Only  '  BQ'  and  '  NE'  are  valid  for  attribute  types  '  STR'  and  '  K3TR' . 
Attribute  types  of '  aint' , '  ARSP' ,  and  '  ardp'  may  not  be  used  in  a  condition.  Also,  for  attributes 
of  type  '  STR'  or  '  KSTR' ,  their  length  must  be  8  or  fewer  characters.  Note  that  string  attribute 
values  are  passed  as  hollerith  data. 

2.  Any  RECOND  call  removes  any  existing  conditions,  that  is,  it  performes  an  RECLRC  internally. 

Error  Conditions: 

None 
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Database  Relational  Utility  Module:  RECPOS 

Entry  Point:  RECPOS 

Purpose: 

lb  position  to  a  specific  entry  and  return  the  row  number,  if  present. 
MAPOL  Calling  Sequence: 

None 


Application  Calling  Sequence: 

CALL  RECPOS  (  RELNAM,  KEY ,  VAL,  RGW2IDM  > 

reliiam  Name  of  the  relation  (Character,  Input) 

KEY  Name  of  a  keyed  attribute  (Character,  Input) 

VAL  The  desired  value  of  the  keyed  attribute  (Integer,  Input) 

rownum  The  row  number  satisfying  the  condition.  If  zero,  no  entries  were  found 

(Integer,  Output) 

Method: 

None 


Design  Requirements: 

1.  If  the  key  is  a  character  attribute,  it  must  hi  oi  length  eight  and  VAL  must  contain  the  hollerith 
representation  of  the  desired  value.  The  conversion  from  character  to  hollerith  must  be  made  with 
the  demdch  routine. 


Error  Conditions: 
None 
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Database  Relational  Utility  Module;  BSSNDC 

Entry  Point:  REENDC 

Purpose: 

Tb  end  the  definition  for  a  relational  entity. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALI.  SEENDC 

Method: 

None 

Design  Requirements: 

None 


Error  Conditions: 
None 


Database  Relational  Utility  Module:  REGB 

Entry  Point:  REGB 

Purpose: 

lb  fetch  all  of  the  entries  of  the  requested  relation  that  satisfy  the  specified  projection  and  constraints 
(see  also  REGBM). 

MAPOL  Calling  Sequence: 

None 

Application  Calling  jequence: 

CMJL  RHSSB  {  RE UWA,  BOT,  INUM,  ISTAT  ) 

SELKfiK  Name  of  the  relation  (Character,  Input) 

BUF  Array  that  will  contain  the  entries  (Any,  Output) 

intm  The  number  of  entries  fetched  (Integer,  Output) 

1 3 TAT  Status  return  (Integer,  Output) 

Q  entries  successfully  fetched 

201  no  entries  found 

Method: 

None 

Design  Requirements: 

1.  Only  integer  or  real,  single-precision  or  string  attributes  may  be  fetched  with  this  routine. 

Error  Conditions: 

None 
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Database  Relational  Utility  Module:  REGBM 

Entry  Point:  REGBM 

Purpose: 

lb  fetch  all  of  the  entries  of  the  requested  relation  that  satisfy  the  specified  projection  and  constraints 
and  that  contain  double-precision,  or  mixed  precision  attributes. 

MAPOL  Calling  Sequence: 


ation  (Jailir 


sequence: 


call  mam  :  kelham,  stosl,  oble,  inom,  is  tat  ) 


HELMAM 


ISTAT 


Method: 


Design  Requirements: 


Name  of  the  relation  (Character,  Input) 

Array  that  will  contain  single-precision  entry  data  (Integer,  Real  Single¬ 
precision,  or  String,  Output) 

Array  that  will  contain  double-precision  entry  data  (Double,  Output) 

The  number  of  entries  fetched  (Integer,  Output) 

Status  return  (Integer,  Output) 

0  entries  successfully  fetched 

201  no  entries  found 


Error  Conditions: 


Database  Relational  Utility  Module:  REGET 

Entry  Point:  REGET 

Purpose: 

Tb  fetch  an  entry  of  a  relation  that  satisfies  the  given  projection  and  constraint  conditions. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  RESET  {  RELNAM,  BUT,  ISTAT  ) 

relnam  Name  of  the  relation  (Character,  Input) 

buf  Array  that  will  contain  the  entry  data  (Any,  Output) 

ISTAT  Status  return  (Integer,  Output) 

0  entries  successfully  fetched 

201  no  entries  found 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Relational  Utility  Module:  REGETM 
Entry  Point:  REGETM 


Purpose: 

Tb  fetch  an  entry  of  a  relation  that  satisfies  the  given  projection  and  constraint  conditions,  and  that 
contains  double-precision,  or  mixed  precision  attributes. 

MAPOL  Calling  Sequence: 

None 


Application  Calling  Sequence: 


CALL  REGETM  (  RELNAM,  SNGL,  DBLE.  ISTAT  ) 


RELNAM 

SNGL 

DBLE 


Name  of  the  relation  < Character,  Input) 

Array  that  will  contain  single-precision  entry  data  (Integer,  Real  Single¬ 
precision,  or  String)  (Any,  Output) 

Array  that  will  contain  double-precision  entry  data  (Double,  Output) 


ISTAT  Status  return  (Integer,  Output) 

0  entries  successfully  fetched 

201  no  entries  found 


Method: 

None 

Design  Requirements: 
None 

Error  Conditions: 
None 
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Database  Relational  Utility  Module:  RENULx 
Entry  Points:  RENULD,  RENULI,  RENULR,  RENULS 
Purpose: 

lb  check  if  a  double-precision,  integer,  real,  or  character  attribute  has  a  null  value.  Attributes  excluded 
from  the  projection  when  a  relational  entry  is  added  are  given  such  null  values. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequences: 

RENULD  {  FIELDD  ) 

RENULI  (  FIELD!  ) 

RENULR  (  FIELDR  ) 

RENULS  (  FIELDS  ) 

FIELDD 

FIELDI 

FIELDR 

FIELDS 

RENULD 
RENULI 
RENULR 
RENULS 

Method: 

None 

Design  Requirements: 

1.  The  string  attribute,  FIELDS,  must  be  passed  as  a  hollerith. 

Error  Conditions: 

None 


Double  precision  attribute  value  (Input) 
Integer  attribute  value  (Input) 

Real,  single-precision  attribute  value  (Input) 
String  attribute  value  (Input) 

Logical  values  (output)  TRUE  if  FIELDx  is  null 
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Database  Relational  Utility  Module:  RE POS 

Entry  Point:  REPOS 


lb  position  a  relation  to  an  entry  with  a  given  keyed  attribute. 
MAPOL  Calling  Sequence: 


plication  Calling  sequence: 

CALL  REPOS  (  PELHAM,  KEY,  VAL  ) 


RELNAM 


Name  of  the  relation  (Character,  Input) 

Name  of  a  keyed  attribute  (Character,  Input).  The  special  attribute  name 
of '  ENTRYNOM'  with  a  VAL=1  may  be  used  to  reposition  an  entity  to  the 
beginning. 

The  desired  value  of  the  keyed  attribute  (Integer,  Input) 


Method: 


Design  Requirements: 

1.  The  attribute  must  be  keyed. 

2.  If  KEY*'  ENTRYNOM'  then  VAL  must  be  1. 

Error  Conditions: 

1.  A  database  fatal  error  occurs  if  the  requested  entry  does  not  exist. 
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Database  Relational  Utility  Module:  RE  PRO  J 

Entry  Point:  RE  PRO  J 

Purpose: 

lb  define  the  projection,  or  subset  of  attributes,  for  the  relation  prior  to  performing  updates,  adds  or 
gets  of  entries. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  REPROJ  (  BELNAM,  NATTR,  ATTRLIST  ) 

RELKAM  Name  of  the  relation  (Character,  Input) 

nattr  Number  of  attributes  in  the  projection  (Integer,  Input) 

ATTRLIST  Array  containing  the  attribute  names  that  define  the  projection 

(Character,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 


None 


Database  Relational  Utility  Module:  REQURY 


Entry  Point:  REQURY 


Purpose: 

lb  retrieve  the  schema  of  a  relation. 
MAPQL  Calling  Sequence: 

None 

Application  Calling  Sequence: 


CALL  REQURY  (  RELNAM,  NATTR,  ATTRLIST,  ATTRTYPE,  ATTRLEN,  TOTLEN  ) 


RELNAM 

NATTR 

ATTRLIST 

ATTRTYPE 


Name  of  the  relation  (Character,  Input) 

Number  of  attributes  (Integer,  Output) 

Array  containing  the  attribute  names  (Character,  Output) 
Array  containing  the  attribute  types  (Character,  Output) 


ATTRLEN 


TOTLEN 

Method: 

None 

Dosign  Requirements: 
None 

Error  Conditions: 
None 


'INT' 

Integer  attribute 

'HINT' 

Keyed  integer  attribute 

'  AINT' 

Array  of  integers 

'RSP' 

Real,  single-precision  attribute 

'  ARSP' 

Array  of  single-precision 

'RDP' 

Real,  double-precision  attributes 

' ARDP' 

Array  of  double-precision 

'STR' 

String  attribute 

'KSTR' 

Keyed  string  attribute 

Array  defining  the  number  of  elements  in  an  array  attribute  or  the  num¬ 
ber  of  characters  in  a  string  attribute  (Integer,  Output) 

Tbtal  length  of  schema  in  words  (Integer,  Output) 
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Database  Relational  Utility  Module:  RESCHM 
Entry  Point:  RESCHM 


Purpose: 

lb  define  the  schema  of  a  relation  being  created  by  a  functional  module. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 


CALL  RESCHM  (  RELNAM,  NATTR,  ATTRLIST,  ATTRTYPE ,  ATTRLEN  ) 


RELNAM 

NATTR 

ATTRLIST 

ATTRTYRE 


Name  of  the  relation  (Character,  Input) 

Name  of  attributes  (Integer,  Input) 

Array  containing  the  attribute  names  (Character,  Input) 
Array  containing  the  attribute  types  (Character,  Input) 


'  INT' 

Integer  attribute 

'KINT' 

Keyed  integer  attribute 

'  AINT' 

Array  of  integers 

'  RSP' 

Real,  single-precision  attribute 

' ARSP' 

Array  of  single-precision 

'RDR' 

Real,  double-precision  attributes 

'  AR33P' 

Array  of  double-precision 

'STR' 

String  attribute 

'KSTR/ 

Keyed  string  attribute 

ATTRLEN  Array  defining  the  number  of  elements  in  an  array  attribute  or  the  num¬ 

ber  of  characters  in  a  string  attribute  (Integer,  Input) 

Method: 

None 

Design  Requirements: 

1.  The  relation  relnam  must  not  already  have  a  schema  defined. 

2.  Keyed  attributes  must  have  uniform  values  for  all  rows. 

3.  No  attributes  may  have  the  name  '  ENTRYNtJM' 

4.  Attributes  of  the  type  '  KSTR'  must  have  length  of  8  or  fewer  characters. 

Error  Conditions: 

None 
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Database  Relational  Utility  Module:  resetc 

Entry  Point:  RESETC 

Purpose: 

lb  define  additional  conditions,  or  constraints,  for  a  relational  attribute  prior  to  performing  a  gat 
operation  (see  also  second). 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  RESETC  (  BOOL,  ATTERNAM,  RELOP,  VAL  ) 

bool  The  boolean  operation  '  or.'  or  '  AND'  (Character,  Input) 

ATTRNAM  Name  of  the  attribute  (Character,  Input) 

RELOP  The  relational  operator  for  the  constraint;  one  of  'EQ' ,  'US' , '  ST' , 

'  LT' , '  GE* , '  LE' ,  'MAX' ,  'MSN'  (Character,  Input) 

VAL  The  value  to  be  tested  (Any,  Input) 

Method: 

None 

Design  Requirements: 

1.  VAL  must  be  the  same  type  as  the  ATTKMAKL  Amaxinmm  of  10  conditions  may  be  specified.  All  RELOPs 
are  legal  for  attributes  of  type  '  XOT' , '  KINT' , '  RSP' ,  and  '  RDP' .  Only  '  EQ'  and  '  NE'  are  valid 
for  attribute  types '  STR'  and  '  kstr'  .  Attribute  types  of '  AINT' , '  ARSP' ,  and  '  ABDP'  may  not  be 
used  in  a  condition.  Also,  for  attributes  of  type  '  STR'  or  '  KSTR' ,  their  length  must  be  8  or  fewer 
characters.  Only  one  condition  may  have  a  '  MAX'  or '  MIN'  RELOP.  Note  that  string  attribute  values 
are  passed  as  hollerith  data. 

Error  Conditions: 

None 
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Database  Relational  Utility  Module:  RESORT 
Entry  Point:  RESORT 
Purpose: 

Tb  sort  a  relation  on  one  or 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  RESORT  {  RELNAM, 

RELNAM 
HATTR 
30RTYPE 


ATTRLIST 
KORE 

Method: 

None 

Design  Requirements: 

1.  The  sort  sequence  is  performed  in  the  order  that  the  attributes  are  specified  in  ATTRLIST. 

2.  The  relation  relnam  must  be  closed  when  resort  is  called. 

Error  Conditions: 

None 


more  of  its  attributes. 


NATTR,  SORTTIPE ,  ATTRLIST,  KORE  ) 

Name  of  the  relation  (Character,  Input) 

The  number  of  attributes  to  be  sorted  (Integer,  Input) 
The  type  of  sort  for  each  attribute  (Character,  Input) 

'ASC'  Ascending 

'DES'  Descending 

A  list  of  the  attributes  to  be  sorted  (Character,  Input) 
Base  address  of  open  core  (Input) 
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Database  Relational  Utility  Module:  REUPD 

Entry  Point:  REUPD 

Purpose: 

Tb  update  the  current  relational  entry. 

MAPQL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  REUPD  (  RELNM4,  BUF  ) 

RELNAM  Name  of  the  relation  (Character,  Input) 

BUF  Array  that  contains  updated  entry  data  (Any,  Input) 

Method: 

None 

Design  Requirements: 

1.  Only  integer,  single-precision  or  string  attributes  may  be  updated  with  this  routine. 
Error  Conditions: 


Database  Relational  Utility  Module:  REUPDM 
Entry  Point:  REUPDM 


Purpose: 

lb  update  the  current  relational  entry  that  contains  double-precision,  or  mixed  precision,  attributes. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 


CALL  REUPDM  (  SELNAM,  3NSL,  DBLE  ) 


RSL&AM 

SMGL 

DELS 


Name  of  the  relation  (Character,  Input) 

Array  that  contains  the  single-precision  entry  data  (Any,  Input) 
Array  that  contains  the  double-precision  entry  data  (Double,  Input) 


Method: 

None 

Design  Requirements: 
None 

Error  Conditions: 
None 
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8.7.  UTILITIES  FOR  UNSTRUCTURED  ENTITIES 

Unstructured  database  entities  are  used  primarily  for  scratch  I/O  by  modules  or  for  saving  data 
that  are  generally  used  on  an  all-or-nothing  basis  That  is,  random  access  to  anything  other  than  a 
complete  record  is  not  used.  The  utilities  to  support  this  type  of  data  are  shown  below: 


SUBROUTINE 

FUNCTION 

UNPOS 

Positions  to  a  given  unstructured  record 

UNRBOS 

UNSEAT 

Returns  the  length  of  a  record 

UNSET 

Gets,  or  fetches,  an  entire  record 

UN3ETP 

Gets,  or  fetches,  a  partial  record 

UHPUT 

Adds  a  new  record  to  the  unstructured  entity 

UNPUTP 

Add3  a  partial  record  to  the  entity 

8.7.1.  3en®rating  an  Unstructured  Entity 

As  seen  in  Subsection  8.2,  the  first  step  in  generating  any  entity  is  to  perform  a  OBCHEA.  This  is 
followed  by  a  OBOPEH,  any  desired  I/O  activity,  and  finally  a  DBCLOS.  Suppose,  for  example,  the  local 
coordinates  X,  Y,  and  Z  of  1000  grid  points  have  been  computed  and  are  in  a  block  of  dynamic  memory 
called  8RID  whose  location  pointer  is  TGRD  (see  Section  8.3).  Further,  assume  that  these  coordinates  have 
also  been  converted  to  the  basic  coordinate  system,  and  that  these  transformed  coordinates  are  located  in 
block  hero  with  pointer  isnd.  These  data  will  be  used  in  a  subsequent  routine  or  module  in  their 
entirety.  It  will  therefore  be  written  into  an  unstructured  entity  called  COORD  in  two  distinct  records.  The 
code  segment  to  perform  this  is  shown  below: 

wMOhi.  m  ■  ww»hiihh.jiiii  i— i  ■■■«■■  —  ■— i 

C 

C  CREATE  THE  NEW  ENTITY  AND  OPEN  FOR  I/O 

C 

CALL  DECREA  ! '  COC-RD' ,  '  IUN'  ) 

CALL  DBOPEN  {'COORD',  INFO,  ' R/W' ,  'FLUSH',  ISTAT) 

C 

C  WRITE  THE  TWO  UNSTRUCTURED  RECORDS 

C 

CALL  UN PUT  ('COORD',  Z  (IGRD) ,  3000) 

CALL  UNPUT  ('COORD',  Z  (IGND) ,  3000) 

n 

C  I/O  COMPLETE  CLOSE  ENTITY 

C 

_  CALL  DBCLOS  ('COORD') 


The  UNPUT  call  loads  a  complete  record  into  the  entity.  Therefore,  the  above  operations  generate 
two  records  in  coord.  If  an  operation  is  being  performed  "on-the-fly,"  or  complete  records  do  not  fit  in 
memory,  then  a  "partial"  put,  UNPtm?,  may  be  performed. 
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Now  assume  that  the  local  coordinates  are  all  in  memory,  but  that  the  transferred  coordinates 
will  be  generated  on  a  pointby-point  basis  and  written  to  the  coord  entity.  Subroutine  TRAK3F  trans¬ 
forms  a  set  of  three  local  coordinates  to  basic  coordinates  stored  in  a  local  array  xnew.  This  is  illustrated 
below: 


c 

C  CREATE  AND  OPEN  THE  ENTITY 

C 

CALL  DBCREA  ('COORD',  'UN') 

CALL  DBOPEN  ('COORD',  INFO,  ' R/W' ,  'FLUSH',  ISTAT) 
C 

C  FIRST  WRITS  THE  LOCAL  COORDINATE 

C 

CALL  UNPUT  ('COORD',  Z  (IGRD) ,  3000) 

C 

C  NEXT,  COMPUTE  NEW  COORDINATES  ONE-AT-A-TIME 

C 

DO  100  1=0,2999,3 

CALL  TRANSF  (Z  (IGRD+I),  XNEW) 

CALL  UNPUT P  ('COORD',  XNEW,  3) 

100  CONTINUE 

C 

C  TERMINATE  PARTIAL  RECORD  AND  CLOSE 

C 

CALL  UNPUT  ('COORD',  0,0) 

CALL  DBCLOS  ( ' COORD' ) 


Note  that  a  record  of  an  unstructured  entity  that  i3  created  by  partial  puts  must  be  "closed"  by  a 
call  to  UNPUT.  In  this  case,  the  final  put  operation  does  not  extend  the  record  but  only  terminates  it. 

8.7.2.  Accessing  an  Unstructured  Entity. 

The  UNPUT  and  UNPUTP  utilities  have  direct  analogs  in  UNGET  and  ungetp  for  the  retrieval  of 
data.  Three  other  utilities  are  available  for  data  access.  The  first  two,  unpos  and  unrpos,  allow  an 
unstructured  entity  to  be  positioned  to  a  specific  record.  Note  that  this  access  is  much  faster  if  the  entity 
was  created  W‘h  an  index  structure,  that  is,  the  DBCREA  call  specified  type  '  IUN' .  The  third  utility, 
unstat,  is  useu  to  find  length  of  a  given  record.  These  utilities  are  demonstrated  in  the  example  below, 
the  second  record  of  COORD  will  be  accessed  and  each  coordinate  set  used  individually.  It  is  not  assumed 
that  the  number  of  grid  points  is  known  to  this  application. 
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OPEN  THE  ENTITY,  READONLY  MODE 


CALL  DBOPEN  {'COORD',  INFO,  '  RO' ,  'NOFI.USH',  ISTAT) 

NOFLUSH  PROTECTS  AGAINST  DESTROYING  THE  DATA, 

NOW,  POSITION  TO  RECORD  2,  GET  LENGTH  OF  RECORD 

CALL  UNPOS  ('COORD',  2) 

CALL  UN ST AT  ('COORD',  IREC,  LEN) 

LEN  IS  THE  NUMBER  OF  WORDS  IN  THE  RECORD, 

FETCH  AND  USE  COORDINATES  ONE-AT-A-TIME 

NGRID=LEN/3 
DO  100  1=1,  NGRID 

CALL  UNGETP  ('COORD',  XNEW,  3) 

USE  THE  XNEW  VALUES  HERE 

CONTINUE 

I/O  COMPLETE,  CLOSE  THE  ENTITY 
CALL  DBCLOS  ('COORD') 


8.7.3.  Modifying  an  Unstructured  Entity. 


! 


It  is  also  possible  to  modify,  or  update,  the  contents  of  an  individual  record  within  an  unstruc¬ 
tured  entity.  The  only  limitation  to  this  feature  is  that  the  length  of  the  record  must  be  the  same  as,  or 
less  than,  the  length  of  the  originally  created  record. 
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Database  Unstructured  Utility  Module:  unget 

Entry  Point:  UNGET 
Purpose: 

Tb  fetch  a  complete  record  from  an  unstructured  entity. 

MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UNSET  (  NAME,  ARAY ,  NWOBD  ) 

NAME  Name  of  the  unstructured  entity  (Character,  Input) 

arax  Array  that  will  contain  the  unstructured  record  (Integer,  Output) 

NKOKD  The  number  of  single-precision  words  to  be  transferred  (Integer,  Input) 

Method: 

If  nword  is  less  than  the  total  number  of  words,  the  remaining  data  will  not  be  retrieved.  UNSET  positions 
the  entity  to  the  next  record  after  the  retrieval. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Unstructured  Utility  Module:  UNGETP 
Entry  Point:  UNGETP 


Purpose: 

Tb  fetch  a  portion  of  an  unstructured  record. 

MAPQL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UNGETP  (  NAME,  ARAY,  NWORD  ) 

NAME  Name  of  the  unstructured  entity  (Character,  Input) 

aray  Array  that  will  contain  the  unstructured  record  (Integer,  Output) 

NWOKD  The  number  of  single-  precision  words  to  be  transferred  (Integer,  Input) 

Method: 

Following  the  retrieval,  the  entity  is  still  positioned  at  the  same  record,  a  subsequent  UNSET  or  UNGETP 
will  get  the  next  words  in  the  record. 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Unstructured  Utility  Module: 


UNPOS 


Entry  Point:  UNPOS 
Purpose: 

Tb  position  an  unstructured  entity  to  a  specific  record. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 


CALL  UNPOS  (  NAME, 
NAME 
RECNO 

Method: 

None 

Design  Requirements: 
None 

Error  Conditions: 

None 


RECNO  ) 

Name  of  the  unstructured  entity  (Character,  Input) 
Record  number  (Integer,  Input) 
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Database  Unstructured  Utility  Module:  UNPUT 

Entry  Point:  UNPUT 

Purpose: 

Tb  add  a  record  to  an  unstructured  entity.  The  record  is  terminated  after  the  transfer. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UNPUT  (  NAME , 

NAME 
ARAX 
NWORD 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 


ARAX,  NWORD  ) 

Name  of  the  unstructured  entity  (Character,  Input) 
Array  containing  the  record  to  be  added  (Any,  Input) 
The  number  of  words  to  be  transferred  (Integer,  Input) 
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Database  Unstructured  Utility  Module:  UNPUTP 
Entry  Point:  UNPUTP 


Purpose: 

Tb  add  a  partial  record  to  an  unstructured  entity.  The  record  is  not  terminated  after  the  transfer. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 


CALL  UNPUTP  (  NAME, 
NAME 
ARAY 
NWORD 


ARAY ,  NWORD  ) 

Name  of  the  unstructured  entity  (Character,  Input) 
Array  containing  the  record  to  be  added  (Any,  Input) 
The  number  of  words  to  be  transferred  (Integer,  Input) 


Method: 

None 

Design  Requirements: 
None 

Error  Conditions: 
None 
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Database  Unstructured  Utility  Module:  UNRPOS 

Entry  Point:  UNRPOS 

Purpose: 

Tft)  position  an  unstructured  entity  to  a  specific  record  defined  as  an  increment  from  the  current  record. 
MAPOL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UNSTAT  (  NAME,  DELRID  ) 

name  Name  of  the  unstructured  entity  (Character,  Input) 

DELRID  Record  number  increment  relative  to  the  current  position  (Integer,  Input) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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Database  Unstructured  Utility  Module:  UNSTAT 
Entry  Point:  UNSTAT 


Purpose: 

Tb  return  the  length,  in  single-precision  words,  of  the  current  record. 

MAPQL  Calling  Sequence: 

None 

Application  Calling  Sequence: 

CALL  UNSTAT  (  NAME,  RECNO,  LEK  ) 

NAME  Name  of  the  unstructured  entity  (Character,  Input) 

RECNO  Current  record  number  (Integer,  Output) 

len  Record  length  in  single-precision  words  (Integer,  Output) 

Method: 

None 

Design  Requirements: 

None 

Error  Conditions: 

None 
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9.  DATABASE  ENTITY  DESCRIPTIONS 


All  intermodular  communication  in  ASTROS  is  done  through  data  stored  on  the  CADDB  database. 
As  a  resu't,  there  are  many  relations,  matrices,  and  unstructured  entities  that  are  defined  to  store  the  data 
requisite  to  the  analyses.  This  section  provides  a  description  of  each  of  the  database  entities  that  are  used 
in  the  ASTROS  system.  These  data  are  useful  both  to  the  ASTROS  programmer,  who  needs  to  know  the 
description  of  each  of  the  entities  to  interpret  and  modify  the  ASTROS  source  code,  and  to  the  general  user 
in  that  these  data  are  available  on  the  database  for  other  uses  such  as  the  Interactive  CADDB  Interface, 
ICE.  For  supplementary  post-processing,  the  matrix  entities  may  be  combined  using  the  MAPOL  language 
to  generate  data  not  otherwise  computed.  At  a  more  sophisticated  level,  a  user-written  Fortran  module  may 
take  existing  data  from  the  entities  to  perform  more  advanced  operations  that  are  beyond  the  capabilities 
of  the  ASTROS  executive  system. 

The  entities  are  documented  in  alphabetical  order  and  every  entity  which  is  used  in  intermodule 
communication  is  included.  Those  entities  which  are  used  for  scratch  storage  within  a  module  are 
documented  in-line  rather  than  in  the  Programmer’s  Manual.  The  entities  presented  here  fall  into  three 
categories:  system  level,  hidden  entities,  and  MAPOL  entities.  The  first  include  those  entities  that 
communicate  system  information  between  modules.  The  hidden  and  MAPOL  entities  are  those  which  are 
declared  in  the  MAPOL  sequence  itself.  The  hidden  entities  do  not  subsequently  appear  in  the  MAPOL 
sequence;  their  declaration  is  included  as  a  convenience  to  the  ASTROS  executive  system.  The  most  common 
example  of  a  hidden  entity  is  any  relation  assc. dated  with  a  Bulk  Data  entry.  These  relations  are  used 
internally  by  numerous  modules  but  they  do  not  appear  in  the  MAPOL  calling  sequences  because  their 
inclusion  would  result  in  an  impractically  large  number  of  arguments.  MAPOL  entities  are  the  most  relevant 
and  include  most  matrix  entities  and  a  large  number  of  relational  entities  that  are  used  to  pass  data  between 
engineering  modules. 

The  entity  documentation  format  is  slightly  different  for  each  of  the  entity  classes.  The  core 
information,  however,  is  the  same  for  each  class  and  includes  the  entity  name,  a  description  of  its  contents, 
the  modules  that  create  or  add  data  to  the  entity,  and  any  additional  notes  required  to  define  special  data 
handling  functions.  Each  entity  class  then  has  an  additional  set  of  information. 

Matrix  entities  have  a  section  labeled  Matrix  Form,  which  gives  the  row  and  column  dimensions  of 
the  matrix  and  indicates  the  numeric  precision  and  the  form  of  the  entity.  Relational  entities  have  a  section 
called  Relation  Attributes  which  lists  the  schema  of  the  relation  and  defines  the  meaning  of  each  of  the 
attributes.  Finally,  unstructured  entities  have  have  a  section  labeled  Entity  Structure  which  lists  and  defines 
the  number  and  contents  of  the  records  of  the  entity. 
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Entity:  AA 

Entity  Type:  Matrix 

Description:  Acceleration  in  the  a-set  merged  from  the  AL  and  AR  matrices  (see  AG). 

Entity:  AAICMAT 

Entity  (type:  Subscripted  Matrix 

Description:  Aerodynamic  influence  coefficient  matrix  for  an  antisymmetric  boundary  condi¬ 

tion  and  a  given  Mach  number  The  Mach  number  associated  with  a  given  sub¬ 
script  is  given  in  the  TRIM  relation. 

Matrix  Form:  Square,  real  and  asymmetric.  The  dimension  of  the  matrix  is  equal  to  the  number 

of  panels  in  the  steady  aerodynamics  USSAERO  model. 

Created  By:  Module  STEADY 

Notes: 

1.  STEADY  creates  as  many  matrices  as  there  are  distinct  antisymmetric  Mach 
numbers  in  the  user’s  input  packet.  If  a  combination  of  symmetric  and  anti¬ 
symmetric  Mach  numbers  are  used,  the  MINDEX  changes  for  each  distinct 
Mach  number.  An  AAICMAT  entity  is  created  for  a  given  MINDEX  only  if 
the  corresponding  Mach  number  requires  the  antisymmetric  boundary  condi¬ 
tions.  It  is  possible,  therefore,  that,  in  the  range  from  1  to  MINDEX,  some 
subscript  values  will  not  have  a  corresponding  AAICMAT. 
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Entity: 

Entity  Type: 
Description: 

Entity  Structure: 


ACPT 

Unstructured 

Contains  one  record  for  each  independent  group  of  aerodynamic  elements  with 
data  needed  to  generate  the  aerodynamic  matrices. 


RECORD 

WORD 

TYPE 

ITEM 

1 

I 

Key  word,  1  for  doublet  lattice 

2 

I 

Number  of  panels,  NP 

3 

I 

Number  of  strips,  NSTRIP 

4 

I 

Number  of  boxes,  NTP 

5 

R 

F,  fraction  of  box  chord  from  center  of 
pressure  to  downwash  center 

NP  WORDS 

I 

NCARAY,  boxes  per  chord 

NP  WORDS 

I 

NBARAY,  last  box  on  panel 

1 

NSTRIP 

WORDS 

R 

YS  aero  coordinates  of  strip 

NSTRIP 

WORDS 

R 

ZS  center 

NSTRIP 

WORDS 

R 

EE  strip  half  width 

NSTRIP 

WORDS 

R 

SG  sine  of  dihedral  angle 

NSTRIP 

WORDS 

R 

CG  cosine  of  dihedral  angle 

NTP  WORDS 

R 

XIC  coordinate  of  center  of  pressure 

NTP  WORDS 

R 

DELX  box  chord 

NTP  WORDS 

R 

XLAM  tangent  of  sweepback  angle 

NTP  WORDS 

R 

TR  box  taper  ratios 

1 

I 

Key  word,  2  for  Doublet  Lattice  with 

Bodies 

2 

I 

NJ,  Number  of  J  points 

2 

3 

I 

NK,  Number  of  K  points 

4 

I 

NP,  Number  of  Panels 

5 

I 

NB,  Number  of  Bodies 

6 

I 

NTP,  Number  of  Boxes 

7 

I 

NBZ,  Number  of  Z  Bodies 

8 

I 

NBY,  Number  of  Y  Bodies 

401 


RECORD 


WORD 


TYPE 


ITEM 


— 

2 

(cont) 

9 

I 

NTZ,  Number  of  Z  Interference  Body  j 

Elements  ; 

10 

I 

NTY,  Number  of  Y  Interference  Body 
Elements 

11 

I 

NTO,  Sum  of  NTP  +  NTZ  +  NTY 

12 

I 

NTZS,  Number  of  Z  Slender  Body 

Elements 

13 

I 

NTYS,  Number  of  Y  Slender  Body 

Elements 

14 

I 

NSTRIP,  Number  of  strips  on  panels 

NP  WORDS 

I 

NCARAY,  Boxes  per  chord 

NP  WORDS 

I 

NBARAY,  Last  box  on  panel 

NP  WORDS 

I 

NAS,  Associated  bodies  per  panel 

*NBEA1,  Number  of  interference  elements 

NB  WORDS 

I 

*NBEA2,  Z-Y  flag 

NB  WORDS 

I 

*NSBEA,  Number  of  slender  elements 

NB  WORDS 

R 

ZB,  Z  Body  center 

NB  WORDS 

R 

YB,  Y  Body  center 

NB  WORDS 

R 

AVR,  Half- width  of  body 

NB  WORDS 

R 

ARB,  Cross-section  aspect  ratio 

NB  WORDS 

I 

NFL,  0=distribution  per  body 

NB  WORDS 

R 

XLE,  X-leading  edge 

NB  WORDS 

R 

XTE,  X-trailing  edge 

NB  WORDS 

I 

NT121,  number  01’s  for  bodies 

NB  WORDS 

I 

NT122,  number  82’s  for  bodies 

NB+STRIP 

R 

ZS,  Z  -  of  strip  center 

NB+STRIP 

R 

YS,  Y  -  of  strip  center 

NSTRIP 

WORDS 

R 

EE,  strip  half-width 

NSTRIP 

WORDS 

R 

SG,  sine  of  dihedral  angle 

NSTRIP 

WORDS 

R 

CG,  cosine  of  dihedral  angle 

NTP+ 

INBEA1 

R 

X,  3/4  chord 

NTP+ 

INBEA1 

R 

DELX,  box  chord 

NTP  WORDS 

R 

XIC,  coordinates  of  center  of  pressure 

RECORD 

WORD 

- — 

TYPE 

ITEM 

NTP  WORDS 

R 

XLAM,  tangent  of  sweepback  angle 

ENSBEA 

WORDS 

R 

AO,  half-widths  for  bodies 

XNSBEA 

WORDS 

R 

XIS1,  X  -  of  slender  leading  edge 

XNSBEA 

WORDS 

R 

XIS2,  X  -  of  slender  trailing  edge 

ZNSBEA 

WORDS 

R 

AOP,  X-derivatives  of  body  half-width 

2 

(cont) 

INBEA1 

WORDS 

R 

RLA,  Radius  of  interference  elements 

INAS 

WORDS 

I 

NASB,  associated  bodies 

ZNFL 

WORDS 

I 

IFLA1,  body  with  01  distribution 

ZNFL 

WORDS 

I 

IFLA2,  Body  with  92  distribution 

INT121 

WORDS 

R 

TN1A,  91’s  for  bodies 

INT122 

WORDS 

R 

TN2A,  92’s  for  bodies 

*Sum  of  entries  is  noted  by  NBEAi,  where  i  =  1,  2 
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Entity: 

Entity  Type*: 
Description: 

Relation  Attributes: 


Created  By:. 
Notes: 


M,  COMPS 
Relation 

Contains  data  on  the  aerodynamic  components  in  the  planar  and  nonplanar 
steady  aerodynamics  model. 


NAME 

TYFE/KEY 

DESCRIPTION 

MODEL 

Integer 

Planar  or  nonplanar  steady  aerodynamics 
model  identifier 
=  1  for  planar  model 
=  --I  for  nonplanar  model 

ACID 

Integer 

Component  identification  number 

MACROTY  F E 

Ttext  (8) 

Type  of  macroelement  (CAER06  or  PAER06) 

GROUP 

Integer 

Group  identification  number 

ACMPNT 

Ttext  (8) 

Component  type 

One  of  WING,  FIN,  CANARD,  POD,  or  FUSEL 

TYPE 

Integer  >  0 

Type  of  degree  of  freedom.  For  STEADY  aero 
models  all  DOFs  are  TYPE-1.  Refer  to 
AECOMPU  for  other  types. 

FI INTI D 

Integer 

First  internal  degree  of  freedom  on  the 
macroelement 

NCR  OX 

Integer 

Number  of  chordwise  boxes  for  lifting  surfaces 
or  number  of  circumferential  boxes  for  bodies 

NS  BOX 

Integer 

Number  of  spamvise  boxes  for  lifting  surfaces 
or  number  of  axial  boxes  for  bodies 

BNDRY 

X3  i  !  Coordinates  of  the  component  corners  in  basic 

iv  \ctCt-OT*  1  Xm/  j  i»  . 

j  coordinates 

Module  STEADY 

1.  The  boundary  coordinates  are  the  x,  y,  z  coordinates  for  each  of  the  corners  cf 
lifting  elements.  Body  elements  do  not  use  BNDRY. 

The  data  are  in  the  following  order: 

(1-3)  Leading  Edge  Root 
(4-6)  Trailing  Edge  Root 
(7-9)  Trailing  Edge  Tip 
(10-12)  Leading  Edge  Tip 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

ACID 

Integer 

Component  identification  number 

MACROTYPE 

Text (8) 

type  of  macroelement,  CAEROl  or  CAER02 

GROUP 

Integer 

Group  identification  number 

ACMPNT 

Tfext  (8) 

Component  type 

One  of  WING  or  BODY 

TYPE 

Integer  >  0 

Degree  of  freedom  type 
=2  for  WING  and  Z  body  elements 
=3  for  Y  body  elements 
=4  for  ZY  body  elements 

FIINTID 

Integer 

First  internal  degree  of  freedom  on  the 
macroelement 

NCBOX 

Integer 

Number  of  chordwise  boxes  for  lifting  surfaces 
or  number  of  circumferential  boxes  for  bodies 

NS  BOX 

Integer 

Number  of  spanwise  boxes  for  lifting  surfaces 
or  number  of  axial  boxes  for  bodies 

BNDRY 

R  vector  (12) 

Coordinates  of  the  component  corners  in  basic 
coordinates 

AECOMPU 

Relation 

Contains  data  on  the  aerodynamic  components  in  the  unsteady  aerodynamics 
model. 


Created  By: 
Notes: 


Module  UNSTEADY 

1.  The  boundary  coordinates  are  the  x,  y,  z  coordinates  for  each  of  the  corners  of 
lifting  elements.  Body  elements  do  not  use  BNDRY. 

The  data  are  in  the  following  order: 

(A)  Leading  Edge  Root 

(B)  Trailing  Edge  Root 

(C)  Trailing  Edge  Tip 

(D)  Leading  Edge  Tip 
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Entity: 

Entity  T^pe: 
Description: 
Relation  Attributes: 


Created  By: 

Note: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


AEFACT 

Relation 

Contains  aerodynamic  input  data  as  defined  on  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

VALUE 

Real 

Data  value 

Module  IFP 


1.  This  relation  contains  one  tuple  for  each  value  in  each  set  defined  on  the  AE¬ 
FACT  card  entry. 

AERO 

Relation 

Contains  basic  aerodynamic  data  for  use  in  unsteady  aerodynamics  as  input  from 
the  bulk  data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

ACS  ID 

Integer  >  0 

Coordinate  system  identification  number  for 

the  aerodynamic  coordinate  system 

REFC 

Real  >  0.0 

Reference  length  for  reduced  frequency 

RHOREF 

Real  >  0.0 

Reference  density 

Module  IFP 
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Entity: 
Entity  Type: 
Description: 


Relation  Attributes: 


Created  By: 
Notes: 


AEROGEOM 

Relation 

Contains  the  aerodynamic  planform  geometric  grid  points  for  the  planar  and  non- 
planar  steady  aerodynamics  model.  These  grid  points  are  not  used  for  data  recov¬ 
ery,  but  can  be  used  in  combination  with  the  "elements"  in  CAROGEOM  to  create 
an  ASTROS  PE  model  using  RODs  and  QUADs  that  represents  the  paneling  of 
the  aero  model. 


NAME 

TYPE/KEY 

DESCRIPTION 

MODEL 

Integer 

=1  for  the  planar  model 
=-  1  for  the  nonplanar  model 

GRIDID 

Integer 

Aerodynamic  grid  identification  number 

X 

Real 

Basic  coordinates  of  the  geometric  point 

Y 

Real 

Z 

Real 

STEADY  and/or  STEAD YNP  modules 


1.  These  grid  points  represent  the  airfoil  and  panel  geometry  of  the  aerody¬ 
namic  model  identified  by  the  MODEL  attribute.  The  connectivity  of  these 
grid  points  is  given  in  the  CAROGEOM  entity. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  by: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


AEROS 


Relation 

Contains  the  basic  parameters  for  static  aeroelasticity  as  input  from  the  Bulk 
Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

ACSID 

Integer  >  0 

Aerodynamic  coordinate  system  identification 

RCSID 

Integer  >  0 

Reference  coordinate  system  for  rigid  body 
motions 

REFC 

Real  >  0.0 

Reference  chord  length 

REFB 

Real  >  0.0 

Reference  span 

REFS 

Real  >  0.0 

Reference  wing  area 

GREF 

Integer  >  0 

Reference  grid  point 

REFD 

Real  >  0.0 

Body  component  reference  diameter 

REFL 

Real  >  0.0 

Body  component  reference  length 

Module  IFP 

AESURF 

Relation 

Contains  the  specification  of  an  aerodynamic  control  surface  as  input  from  the 
Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

LABEL 

Ttext  (8) 

Alphanumeric  data  identifying  the  control 
surface 

TYPE 

Tfext  (8) 

Surface  type 

ACID 

Integer  >  0 

Aerodynamic  component  identification  number 
for  control  surface  definition 

CID 

Integer  >  0 

Coordinate  system  defining  the  surface  hinge 
line 

FBOX1 

Integer  >  0 

First  aerodynamic  box  on  the  control  surface 

LBOX1 

Integer  >  0 

Last  aerodynamic  box  on  the  control  surface 

Module  IFP 
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Entity: 
Entity  Type: 
Description: 

Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


AF 

Matrix 

Merged  from  the  AA  matrix  (see  AG). 

AG 

Subscripted  Matrix 

Contains  the  accelerations  of  the  structural  degrees  of  freedom. 

A  variable  sized  matrix  having  one  row  for  each  structural  degree  of  freedom  and 
one  column  for  each  load  condition  in  the  current  boundary  condition. 

MAPOL 


1.  The  dimension  of  this  subscripted  matrix  must  be  large  enough  for  all  optimi¬ 
zation  and  analysis  boundary  conditions. 

2.  This  entity  is  only  filled  for  analysis  of  unrestrained  structures. 

3.  The  MAPOL  sequence  recovers  this  matrix  in  the  following  order  (see  the 
Theoretical  Manual  for  the  explicity  form  of  this  recovery): 


AZ 

AR 

<P 

AA 

<P 

AF 

CM* 

AF 


AA 


-4  AF 


AF 


-4  AG 


*UM  contains  accelerations  in  the  M-set.  The  entity  name  is  reused  in  the 
MAPOL  sequence. 


AGA 

Matrix 

Contains  the  active  acceleration  vectors  for  the  current  boundary  condition. 

A  matrix  having  one  column  for  each  active  acceleration  vector  and  one  row  for 
each  degree  of  freedom  in  the  structural  model. 

MAPOL 

1.  This  entity  is  only  generated  during  sensitivity  evaluation  of  unrestrained 
boundary  conditions. 
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Entity: 

AICMAT 

Entity  Type: 

Subscripted  Matrix 

Description: 

Aerodynamic  influence  coefficient  matrix  for  a  symmetric  boundary  condition  and 
a  given  Mach  number.  The  Mach  number  associated  with  a  given  subscript  is 
given  in  the  TRIM  relation. 

Matrix  Form: 

Square,  real  and  asymmetric.  The  dimension  of  the  matrix  is  equal  to  the  number 
of  panels  in  the  steady  aerodynamics  USSAERO  model. 

Created  By: 

Module  STEADY 

Notes: 

1.  STEADY  creates  as  many  matrices  as  there  are  distinct  symmetric  Mach 
numbers  in  the  user’s  input  packet.  If  a  combination  of  symmetric  and  anti¬ 
symmetric  Mach  numbers  are  used,  the  MENDEX  changes  for  each  distinct 
Mach  number.  An  AICMAT  entity  is  created  for  a  given  MINDEX  only  if  the 
corresponding  Mach  number  requires  the  symmetric  boundary  conditions.  It 
is  possible,  therefore,  that,  in  the  range  from  1  to  MINDEX,  some  subscript 
values  will  not  have  a  corresponding  AICMAT. 

Entity: 

AICS 

Entity  Type: 

Matrix 

Description: 

Steady  aerodynamic  influence  coefficient  matrix  for  a  given  boundary  condition 
in  the  structural  coordinates. 

Matrix  Form: 

Square,  real  and  asymmetric.  The  dimension  of  the  matrix  is  equal  to  the  num¬ 
ber  of  degrees  of  freedom  in  the  f-set. 

Created  By: 

MAPOL 

Notes: 

1.  This  matrix  is  derived  from  splining  the  AICMAT  or  AAICMAT  matrix  to  the 
structural  degrees  of  freedom. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


AIRFOIL 

Relation 

Contains  the  airfoil  properties  to  be  used  in  the  aerodynamic  analyses  as  defined 
on  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

ACID 

Integer  >  0 

Aircraft  component  identification  number 

ACMPNT 

Ttext  (8) 

Component  type  (i.e.  WING) 

CP 

Integer  >  0 

Coordinate  system  identification  number 

CHORD 

Integer  >  0 

AEFACT  setid  for  the  chordwise  division  points 

UST 

Integer  >  0 

AEFACT  setid  for  the  upper  surface  half 
thicknesses 

LST 

Integer  >  0 

AEFACT  setid  for  the  lower  surface  half 
thicknesses 

CAMBER 

Integer  >  0 

AEFACT  setid  for  the  camber  ordinants 

RADIUS 

Real  >  0 

Airfoil  leading  edge  radius 

XI,  Yl,  21 

Real 

Location  of  point  1  in  coordinate  system  CP 

X12 

Real  >  0.0 

Edge  chord  length  in  coordinate  system  CP 

I PANEL 

Integer  >  0 

AEFACT  setid  containing  chordwise  cuts  for 
wing  paneling 

IFP  Module 
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Entity: 
Entity  Type: 
Description: 


Matrix  Form: 


Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 

Entity: 
Entity  Type: 
Description: 


AIRFRC 

Subscripted  Matrix 

Rigid  body  aerodynamic  load  vectors  for  a  given  Mach  number.  There  is  one  vec¬ 
tor  for  each  configuration  parameter  associated  with  the  Mach  index.  There  are 
six  symmetric  parameters:  NX,  NZ,  QACCEL,  THKCAM,  ALPHA  and  QRATE 
and  6  antisymmetric  parameters:  NY,  PACCEL,  RACCEL,  BETA,  PRATE, 
RRATE.  In  addition,  each  symmetric  and  antisymmetric  control  surface  AESURF 
will  generate  a  column.  For  a  given  subscript,  the  AIRFRC  matrix  contains  the 
six  columns  for  the  symmetric  parameters  plus  one  column  for  each  symmetric 
AESURF  if  the  SYMMETRIC  forces  are  needed  for  the  associated  Mach  number. 
It  contains  six  columns  for  the  antisymmetric  parameters  and  one  column  for 
each  antisymmetric  AESURF  if  the  ANTISYMMETRIC  forces  are  needed  for  the 
associated  Mach  number.  If  both  are  needed,  all  12  parameters  and  all  AESURF 
entries  in  the  model  have  columns.  The  ordering  of  the  columns  corresponds  to 
the  order  of  entries  in  the  STABCF  entity. 

Rectangular  and  real.  The  number  of  rows  is  equal  to  the  number  of  panels  in  the 
steady  aerodynamics  model  while  the  number  of  columns  is  equal  to  the  number 
of  entries  in  the  STABCF  relation  that  have  the  same  MACHINDX  value  as  the 
subscript  value.  The  columns  of  AIRFRC  are  stored  in  the  same  order  as  the  en¬ 
tries  in  STABCF.  Refer  to  the  STABCF  entity  for  more  details. 

STEADY  Module 

1.  STEADY  creates  as  many  matrices  as  there  are  distinct  Mach  numbers  in  the 
bulk  data  packet. 

AJJTL 

Matrix 

List  of  unsteady  aerodynamic  matrices  to  compute  panel  pressures  due  to  slopes 
at  the  control  point. 

Square,  complex  matrix  with  the  numbbr  of  rows  and  colums  equal  to  the  number 
of  aerodynamic  panels. 

AMP 

1.  AJJTL  is  a  matrix  list  with  the  number  of  matrices  equal  to  the  number  of  M- 
k  pairs  in  the  input  stream. 


AL 

Matrix 

Acceleration  in  the  l-set  obtained  from  D  and  AR  (see  AG). 
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Entity: 
Entity  Type: 
Description: 

Matrix  Form: 


Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 
Matrix  Form: 


Created  By: 
Notes: 


AMAT 

Matrix 

Matrix  containing  the  sensitivity  of  the  constraints  to  changes  in  the  design  vari¬ 
ables. 

The  number  of  columns  is  equal  to  the  number  of  active  constraints.  The  number 
of  rows  is  equal  to  the  number  of  design  variables. 

ACTCON,  AEROEFFS,  AEROSENS,  FREQSENS,  FLUTSENS,  MAKDFV, 
MKAMAT,  LAMINSNS 

1.  The  columns  are  written  in  the  order  they  appear  on  the  CONST  relation  ex¬ 
cept  that,  for  a  given  boundary  condition,  all  the  constraints  for  a  given  sub¬ 
case  are  grouped  together.  On  the  CONST  relation,  these  constraints  are 
grouped  by  type. 

2.  See  CONST. 

3.  CONST  and  AMAT  are  brought  into  alignment  in  DESIGN  where  the 
CONST  tuples  are  ordered  to  have  all  subcases  grouped  together. 

AR 

Matrix 

Contains  the  accelerations  for  the  support  degrees  of  freedom  (see  AG). 

A  variable  sized  matrix  having  one  row  for  each  support  degree  of  freedom  and 
one  column  for  each  load  condition  in  the  current  boundary  condition. 

Module  INERTIA 

1.  This  matrix  is  only  formed  for  the  analysis  of  unrestrained  structures. 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


ASET 

Relation 

Contains  the  external  grid  identification  numbers  and  components  associated 
with  the  analysis  set  as  defined  on  the  ASET  entries  of  the  Bulk  Data  file. 


Created  By: 
Notes: 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

ASET  identification  number 

GRID1 

Integer  >  0 

Grid  or  scalar  point  identification  number 

COMPNTS 

Integer  >  0 

Component  number;  Zero  for  scalar  points,  1-6 
for  grid  points 

Module  IFP 

1.  Used  by  the  MKUSET  module  to  build  the  USET  relation. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Prescription: 

Relation  Attributes: 


ASET1 

Relation 

Contains  the  external  grid  identification  numbers  and  components  associated 
with  the  analysis  set  as  defined  on  the  ASET1  entries  of  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

ASET  identification  number 

COMPNTS 

Integer  >  0 

Component  number;  Zero  for  scalar  points,  1-6 
for  grid  points 

GRID1 

Integer  >  0 

Grid  or  scalar  point  identification  number 

Module  IFF 

1.  Used  by  the  MKUSET  module  to  build  the  USET  relation. 

ATTACH 

Relation 

Contains  the  definitions  of  aerodynamic  boxes  whose  forces  are  to  be  attached  to 
a  referenced  grid  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0 

Element  identification  number 

MACROID 

Integer  >  0 

Element  identification  number  of  an 
aerodynamic  macroelement 

ID1 

Integer  >  0 

External  box  identification  number  of  the  first 
aero  box  on  the  macroelement 

ID2 

Integer  >  0 

External  box  identification  number  of  the  last 
aero  box  on  the  macroelement 

REFGRD 

Integer  >  0 

The  external  identification  number  of  the 
referenced  grid  point 

Created  By: 


Module  IFP 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 


AXSTA 

Relation 

Contains  the  body  axial  station  parameters  for  the  aerodynamic  model  as  input 
from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

BCID 

Integer  >  0 

Body  component  identification  number 

XSTA 

Real 

X  ordinate  of  body  station 

CBOD 

Real 

Z  ordinate  of  body  station 

ABOD 

Real  >  0.0 

Body  cross-sectional  area  at  XBOD 

YRAD 

Integer  >  0 

AEFA.CT  setid  containing  the  y-ordinates  of 
the  body  section 

ZRAD 

Integer  £  0 

AEFACT  setid  containing  the  Z-ordinates  of 
the  body  section 

Module  IFP 

BDD 

Matrix 

Damping  matrix  in  the  direct  dynamic  set. 

Square  matrix  with  the  number  of  rows  and  columns  equal  to  the  number  of  de¬ 
grees  of  freedom  in  the  d-set. 

DMA 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


BEAMEST 

Relation 

Contains  the  element  summary  data  for  the  BAR  element. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

PID 

Integer  >  0 

Element  property  identification 
number 

SIL1 

Integer  >  0 

Internal  grid  point  id  for  end  A 

SIL2 

Integer  >  0 

Internal  grid  point  id  for  end  B 

ORIENTX 

Real 

Orientation  vector  for  element 

ORIENTY 

Real 

ORIENTZ 

Real 

ICSSV 

Integer  >  0 

The  external  coordinate  system  in 
which  the  orientation  vector  is 
defined. 

PINA,  PINB 

Integer  >  0 

The  offset  pinned  degrees  of  freedom 
for  ends  A  and  B 

OFFSETAX 

Real 

The  offset  vectors  for  ends  A  and  B 

OFFSETAY 

Real 

OFFSETAZ 

Real 

OFFSETBX 

Real 

OFFSETBY 

Real 

OFFSETBZ 

Real 

MIDI 

Integer  >  0 

The  material  id  for  the  element 

AREA 

Real  >  0 

The  beam  cross-sectional  area 

11 

Real  >  0 

The  area  moment  of  inertia  (Plane  1) 

12 

Real  >0 

The  area  moment  of  inertia  (Plane  2) 

TORSION 

Real  >  0 

The  beam  torsional  constant 

NSM 

Real  >0 

The  beam  non  structural  mass 

Cl,  C2,  Dl,  D2 

Real 

Element  stress  recovery  coefficients 

El,  E2,  FI,  F2 

Real 

KFACTl 

Real 

Shear  area  factor  (plane  1) 

K FACT 2 

Real 

Shear  area  factor  (plane  2) 

112 

Real 

Beam  product  of  inertia 
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Created  by: 
Notes: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 


NAME 

TYPE/KEY 

DESCRIPTION 

RlSQR 

Real 

Inertia  term;  Definition  for  design 

R2SQR 

Real 

ALPHA 

Real 

COORD1 

Integer  >  0 

External  coordinate  system  of  end  A 

XI,  Yl,  Z1 

Real 

Basic  coordinates  of  end  A 

COORD2 

Integer  >  0 

External  coordinate  system  of  end  B 

X2 ,  Y2,  Z2 

Real 

Basic  coordinates  of  end  B 

SCON 

Integer 

Stress  constraint  flag 

DESIGN 

Integer 

Design  flag 

STHRM 

Real 

Thermal  stress  term 

STHRMA 

Real 

Thermal  strain  term 

TREFPT 

Integer 

Pointer  to  TREF  entity  for  thermal 
stress/load  evaluation 

Module  MAKEST 


1.  This  relation  contains  one  tuple  for  each  beam  element  in  the  problem.  It  is 
built  from  the  CBAR,  PBAR  and  associated  material  and  design  relations. 

BFRC 

Matrix 

Matrix  of  rigid  body  load  vectors  for  unit  values  of  angle  of  attack,  pitch  rate  and 
trim  surface  deflection. 

Rectangular  real  matrix  with  three  columns  and  rows  equal  to  the  number  of  pan¬ 
els  in  the  unsteady  aerodynamics  model. 

Module  BLASTFIT 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  by: 
Notes: 


Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


BGPDT 

Relation 

Contains  the  coordinates  of  the  grid  points  in  the  basic  coordinate  system. 


NAME 

TYPE/KEY 

DESCRIPTION 

EXTID 

Integer  >  0 

The  grid  or  scalar  point  external  identification 
number 

INTID 

Integer  >  0 

Equivalent  internal  identification  number 

FLAG 

Integer  >  0 

Flag  indicating  the  point  is  a  grid  point  or  a 
scalar  point 

CD 

Integer 

The  displacement  coordinate  system  for  the 
grid  point 

X,  Y,  Z 

Real 

Spatial  coordinates  of  the  point  in  the  basic 
coordinate  system 

Module  BCBGPDT 

1.  This  relation  contains  one  tuple  for  each  grid  or  scalar  point  in  the  problem. 

2.  This  relation  is  built  from  the  GRID,  SPOINT,  EPOINT,  CSTM  and  SEQGP 
relations. 

3.  The  FLAG  equals  6  if  the  point  is  a  grid  point  and  equals  1  if  a  scalar  point 
and  0  if  not  in  the  g-set. 

4.  The  internal  identification  number  is  determined  by  assigning  INTID  in  in¬ 
creasing  order  of  EXTID’s. 

5.  Scalar  points  are  also  denoted  by  CD=-1;  X=Y=Z=0.0. 

BHH 

Matrix 

Damping  matrix  in  the  modal  dynamic  set. 

Square  matrix  with  the  number  of  rows  and  columns  equal  to  the  number  of  de¬ 
grees  of  freedom  in  the  h-set. 

DMA 

1.  Info  (11)  for  the  entity  contains  a  coupled  flag 
=  0  Uncoupled 

=  1  Coupled 

2.  Info  (12)  contains  damping  data 
=  0  Modal  damping  only 

=  1  Viscous  damping  only 
=  2  Both  modal  and  viscous  damping 
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Entity: 

Entity  Type: 
Description. 

Relation  Attributes: 


Created  By: 
Notes: 


BLAST 

Relation 

Contains  the  definition  of  parameters  for  use  in  nuclear  blast  response  analysis 
as  input  from  the  bulk  data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

BLID 

Integer  >  0 

Blast  set  ID 

ALT 

Real  >  0.0 

Aircraft  altitude 

VEL 

Real  >  0.0 

Aircraft  velocity 

WKT 

Real  >  0.0 

Weapon  yield 

HGRD 

Real 

Height  of  the  ground 

KGRD 

Integer 

Flag  denoting  presence  of  ground 

BALT 

Real 

Blast  altitude 

MACH 

Real 

Mach  number 

DELTAX 

Real 

X-distance  from  A/C  to  blast 

DELTAY 

Real 

Y-distance  from  A/C  to  blast 

TMIN 

Real  >  0.0 

Minimum  time  used  in  curve  fit 

TMAX 

Real  >  0.0 

Maximum  time  used  in  curve  fit 

NTIME 

Integer  >  0 

Number  of  time  steps 

BMIN 

Real  >  0 

Minimum  decay  value  used  in  curve  fit 

BMAX 

Real  >  0 

Maximum  decay  value  used  in  curve  fit 

NBETA 

Integer  >  0 

Number  of  decay  values 

SYMXY 

Integer 

Symmetry  flag  for  xy  plane 

XYMXZ 

Integer 

Symmetry  flag  for  xz  plane 

TRSURF 

Tbxt  (8) 

Trim  surface  label 

NZ 

Real 

Load  factor  for  trim  calculation 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


BLGTJA 

Matrix 

A  partition  of  matrix  UGTKAused  in  the  nuclear  blast  analysis  to  spline  aerody¬ 
namic  forces  to  the  structure. 

Rectangular  real  matrix  having  one  row  for  each  structural  degree  of  freedom  in 
the  a-set  and  one  column  for  each  panel  in  the  unsteady  aerodynamics  model. 

Module  BLASTFIT 

BLSTJA 

Matrix 

A  partition  of  matrix  UGTKAused  in  the  nuclear  blast  analysis  to  spline  struc¬ 
tural  displacements  to  the  panel  slopes. 

Rectangular  real  matrix  having  one  row  for  each  structural  degree  of  freedom  in 
the  a-set  and  one  column  for  each  panel  in  the  unsteady  aerodynamics  model. 

Module  BLASTFIT 
BODY 

Relation 

Contains  the  body  configuration  parameters  for  the  aerodynamic  model  as  input 
from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

BCID 

Integer  >  0,  key 

Body  component  id 

ACMPNT 

Text (8) 

Component  type  (i.e.,  POD) 

CP 

Integer  >  0 

Coordinate  system  id  for  geometry  input 

NRAD 

Integer  >  0 

Number  of  equal  body  cuts  used  to  define 
the  body  panels 

X,  Y,  Z 

Real 

Ordinates  of  the  body  in  coordinate  system 
CP 

Module  IFF 
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Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


BTEM 

Matrix 

A  scratch  matrix  in  the  blast  calculation. 

Rectangular  real  matrix  with  the  number  of  rows  equal  to  the  number  of  elastic 
modes  retained  in  the  blast  analysis  and  three  columns. 

MAPOL 

1.  This  matrix  is  the  solution  to  the  equation: 

[  KEQE  ]  *  [  STEM  ]  =  [  GFE  ] 
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Entity: 

Entity  TVpe: 
Description: 

Relation  Attributes: 


Created  By: 


CAEROl 

Relation 

Contains  an  aerodynamic  macroelement  (panel)  in  terms  of  two  leading-edge  loca 
tions  and  side  chords.  This  is  used  for  unsteady  aerodynamics. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0 

Element  identification  number 

PID 

Integer  >  0 

Identification  number  of  property  card.  Used  to 
specify  associated  bodies 

CP 

Integer  >  0 

Coordinate  svstem  for  locating  points  1  and  4 

NS  PAN 

Integer  >  0 

Number  of  spanwise  boxes;  if  a  positive  value 
is  given  NSPAN,  equal  divisions  are  assumed; 
if  zero  or  blank,  a  list  of  division  points  is  given 
at  LSPAN 

NCHORD 

Integer  >  0 

Number  of  chordwise  boxes;  if  a  positive  value 
is  given  NCHORD,  equal  divisions  are 
assumed;  if  zero  or  blank,  a  list  of  division 
points  is  given  at  LCHORD 

LSPAN 

Integer  >  0 

ID  of  an  AEFACT  data  card  containing  a  list  of 
division  points  for  spanwise  boxes.  Used  only  if 
NSPAN  is  zero  or  blank 

LCHORD 

Integer  >  0 

ID  of  an  AEFACT  data  card  containing  a  list  of 
division  points  for  chordwise  boxes.  Used  only 
if  NCORD  is  zero  or  blank 

IGID 

Integer  >  0 

Interference  group  identification  (aerodynamic 
elements  with  different  IGID’s  are  uncoupled) 

XI,  Yl,  Z1 

Real 

Location  of  point  1  in  coordinate  system  CP 

X12 

Real  >  0 

Edge  chord  length  (in  aerodynamic  coordinate 
system)  (Cannot  be  zero  if  X43  is  zero) 

X4 ,  Y4,  Z4 

Real 

Location  of  point  4  in  coordinate  system  CP 

X43 

Real  >  0 

Edge  chord  length  (in  aerodynamic  coordinate 
systemXCannot  be  zero  if  X12  is  zero) 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


CAER02 

Relation 

Contains  the  definition  of  an  aerodynamic  body  for  unsteady  aerodynamics  as  in¬ 
put  from  the  bulk  data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0 

Element  identification  number 

PID 

Integer  >  0 

Property  identification  number 

CP 

Integer  >  0 

Coordinate  system  for  locating  point  1 

NSB 

Integer  >  0 

Number  of  slender  body  elements 

NINT 

Integer  >  0 

Number  of  interference  elements 

LSB 

Integer  >  0 

AEPACT  identification  number  defining 
slender  body  division  points 

LINT 

Integer  >  0 

AEFACT  identification  number  defining 
interference  element  division  points 

IGID 

Integer  >  0 

Interference  group  identification 

XI,  Yl,  Z1 

Real 

Location  of  point  1  in  coordinate  system  CP 

X12 

Real  >  0.0 

Length  of  the  body  in  the  x-axis  of  the 
aerodynamic  coordinate  system 

Module  IFP 
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Entity: 
Entity  Type: 
Description: 


CAER06 

Relation 


Relation  Attributes: 


Created  By: 


Contains  the  definition  of  an  aerodynamic  macroelement  used  in  aerodynamic 
analyses  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

ACID 

Integer  >  0 

Aircraft  component  identification  number 

ACMPNT 

Text  (8) 

Component  type  (i.e.,  WING) 

CP 

Integer  >  0 

Coordinate  system  identification  number  for 
geometry  input 

GROUP 

Integer  >  0 

Group  identification  number 

SPAN 

Integer  >  0 

AEFACT  setid  for  the  division  points  of 
spanwise  boxes 

CHORD 

Integer  >  0 

AEFACT  setid  for  the  chordwise  division  points 

Module  IFP 


Entity: 
Entity  Type: 
Description: 


Relation  Attributes: 


Created  By: 
Notes: 


CARQGEOM 

Relation 

Contains  the  connectivity  data  for  the  aerodynamic  planforir  of  the  planar  and 
nonplanar  steady  aerodynamics  model.  These  elements  are  not  used  for  data  re¬ 
covery,  but  can  be  used  in  combination  with  the  "grids"  in  AEROGEOM  to  create 
an  ASTROS  FE  model  using  RODs  and  QUADs  that  represents  the  paneling  of 
the  aero  model. 


NAME 

TYPE/KEY 

DESCRIPTION 

MODEL 

Integer 

=  1  for  the  planar  model 
=  -1  for  the  nonplanar  model 

EID 

Integer  >  0 

External  aerodynamic  box  identification 
number 

INTEID 

Integer  >  0 

Internal  aerodynamic  box  identification 
number  (aerodynamic  degree  of  freedom 
number)  see  Remark  2 

MACROID 

Integer  >  0 

Macroelement  identification  number  on  which 
the  box  lies 

MAC ROT YP 

Tfext  (8) 

Macroelement  type  (e.g.  PAER06,  CAER06) 

CMPNT 

Tfext  (8) 

Component  type  (FIN,  CANARD,  WING, 

FUSEL,  of  POD) 

NGRID 

Integer  >  0 

Number  of  grids  connected  to  the  box 
=  4  or  3  for  panels 
=  2  for  airfoil  line  segments 

GRID1 

Integer  >  0 

Grid  identification  number  of  an  AEROGEOM 
grid  for  inboard/upstream  location 

GRID2 

Integer  >  0 

Grid  identification  number  of  an  AEROGEOM 
grid  for  inboard/downstream  location 

GRID3 

Integer  >  0 

Grid  identification  number  of  AEROGEOM 
grid  for  outboard/downstream  location 

GRID4 

Integer  £  0 

Grid  identification  number  of  AEROGEOM 
grid  for  outboard/upstream  location 

STEADY  and/or  STEAD YNP  modules 

1.  The  grid  points  referred  to  by  this  relation  are  stored  in  the  AEROGEOM  en¬ 
tity. 

2.  Airfoil  geometry  is  also  defined  by  this  relation  but  the  "elements”  are  line 
segments  not  related  to  the  control  points  of  the  panel  model.  For  these  ele¬ 
ments,  the  internal  identification  number  is  set  to  -  1  rather  than  the  degree 
of  freedom  identifier  in  solution  matrices. 

3.  Airfoil  geometry  is  defined  by  any  and  all  elements  with  NGRID=2. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


CASE 

Relation 

Contains  the  case  parameters  for  each  analysis  vhthin  each  boundary  condition 
as  input  in  the  solution  control  packet- 


NAME 

TYPE/KEY 

DESCRIPTION 

OAFLAG 

Integer  >  0 

Optimize/analyze  flag 
=  1  Optimize 
=  2  Analyze 

BCID 

Integer  >  0 

Boundary  condition  identification 
number 

MPCSETID 

Integer 

Multipoint  constraint  set  identification 
number 

SPCSETID 

Integer 

Single  point  constraint  set 
identification  number 

REDSETID 

Integer 

Guyan  reduction  constraint  set 
identification  number 

SUPSETID 

Integer 

Support  set  identification  number 

METHOD 

Integer 

Real  eigenvalue  extraction  method  set 
identification  number 

DYNRED 

Integer 

Dynamic  reduction  set  identification 
number 

INERTIA 

Integer 

Inertia  relief  mode  shapes  set 
identification  number 

TFSETID 

Integer 

Transfer  function  set  identification 
number 

K2PP 

Text (8) 

K2PP  name 

M2PP 

Text  (8) 

M2PP  name 

B2PP 

Text (8) 

B2PP  name 

K2GG 

Text (8) 

K2GG  name 

M2GG 

Thxt  (8) 

M2GG  name 
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NAME 


TYPE/KEY 


DESCRIPTION 


DISFLAG 

Integer 

Discipline  flag 
=  1  Statics 
=  2  Modes 
=  3  Saero 
=  4  Flutter 
=  5  Transient 
=  6  Frequency 
=  7  Buckling 
=  8  Blast 

=  9  Nonplanar  Saero 

MECHLOAD 

Integer 

Mechanical  load  set  identification 
number 

THRMLOAD 

Integer 

Thermal  load  set  identification  number 

GRAVLOAD 

Integer 

Gravity  load  set  identification  number 

TRIMID 

Integer 

Trim  set  identification  number 

TRIMS YM 

Integer 

. 

Trim  symmetry  flag 
=  -1  Antisymmetric 

=  0  Asymmetric 

=  1  Symmetric 

DCONST 

Integer 

Design  constraint  set  identification 
number 

DCSTRESS 

Integer 

Stress  constraint  set  identification 
number 

DCSTRAIN 

Integer 

Strain  constraint  set  identification 
number 

DLOADID 

Integer 

Dynamic  load  set  identification  number 

DRMETH 

Integer 

Dynamic  response  method 
=  1  Direct 
=  2  Modal 

TIMESTEP 

Integer 

Time  step  set  identification  number 

FREQSTEP 

Integer 

Frequency  step  set  identification 
number 

FFTID 

Integer 

Fast  Fourier  transform  set 
identification  number 

GUSTID 

Integer 

Gust  set  identification  number 

INITCON 

Integer 

Initial  condition  set  identification 
number 

RANDOMID 

Integer 

Random  set  identification  number 

BLASTID 

Integer 

Blast  set  identification  number 
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NAME 


TYPE/KEY 


DESCRIPTION 


BUCKLEID  Integer 


FLUTID 


CONTROL 


DAMP ID 


Integer 


Ttext  (8) 


Integer 


Integer 


A.IRDPRNT  Integer  vector  (12) 


Integer  vector  (12) 


Buckling  eigenvalue  extraction  set 
identification  number 


Flutter  set  identification  number 


Name  of  aerodynamic  extra  point 
splining  matrix 


Damping  set  identification  number 


Extra  point  set  identification  number 

Acceleration  print  selection 
WORD  1  Print  set  identification 
number  >  0,  or 
=  0  NONE 
=  -1  ALL 
=  -2  LAST 

WORD  2  Punch  set  identification 
number 

WORD  3  Print  form 
=  0  Rectangular 
=  1  Polar 

WORD  4  Punch  form 

WORD  5  Piint  frequency  set 

identification  number 

WORD  6  Punch  frequency  set 

identification  number 

WORD  7  Print  iteration  set 

identification  number 

WORD  8  Punch  iteration  set 

identification  number 

WORD  9  Print  mode  set  identification 

number 

WORD  10  Punch  maode  set 

identification  number 

WORD  11  Print  time  set  identification 

number 

WORD  12  Punch  time  set  identification 
number 


Aerodynamic  displacement  print 
selection 


Displacement  print  selection 
WORD  1  Print  set  identification 
number 

WORD  2  Punch  set  identification 
number 

WORD  3  Print  form 
=  0  Rectangular 
=  1  Polar 

WORD  4  Punch  form 


Created  By: 
Notes: 


r 

NAME 

TYPE/KEY 

DESCRIPTION 

ENEP.PRN? 

Integer  vector  (12) 

Strain  energy  print  selection 

FORCPRNT 

Integer  vector  (12) 

Element  force  print  selection 

GPFOPRNT 

Integer  vector  (12) 

Grid  point  force  print  selection 

GPWGPRNT 

Integer  vector  (12) 

Grid  point  weight  generation  print 
selection 

LOADPRNT 

Integer  vector  (12) 

Load  print  selection 

MASSPRNT 

Integer  vector  (12) 

Mass  matrix  print  selection 

MPCFPRNT 

Integer  vector  (12) 

Multi-point  constraint  force  print 
selection 

QHHPRNT 

Integer  vector  (12) 

QHH  matrix  print  selection 

QHJPRHT 

Integer  vector  (12) 

QHJ  matrix  print  selection 

ROOTPRNT 

Integer  vector  (12) 

Flutter  and  normal  modes  eigenvalue 
print  selection 

SPCFPRNT 

Integer  vector  (12) 

Single  point  constraint  force  print 
selection 

STIFPRNT 

Integer  vector  (12) 

Stiffness  matrix  print  selection 

STRAP  RNT 

Integer  vector  (12) 

Strain  print  selection 

STREPRNT 

Integer  vector  ( 12) 

Stress  print  selection 

TPREPRNT 

Integer  vector  (12) 

Trim  pressure  coefficient  print  selection 

VELOPRNT 

Integer  vector  (4) 

Velocity  print  selection 

TRIMPRNT 

Integer 

Steady  aeroelastic  trim  print  toggle 

TITLE 

Tbxt (72) 

User  label  TITLE 

SUBTITLE 

Text  (72) 

User  label  SUBTITLE 

TABEL 

Tbxt (72) 

User  label  LABEL 

Module  Solution 


1.  The  format  of  the  ACCEPRNT  vector  is  typical  of  the  format  of  all  the  print 
selection  vectors.  Additionally,  the  format  for  the  print  set  Identification  num¬ 
ber  in  the  ACCEPRNT  vector  is  typical  of  that  of  the  other  set  Identification 
numbers  in  the  vector. 

2.  The  CASE,  JOB  and  OPTIMIZE  relation  entities  together  contain  the  solu¬ 
tion  control  requests  as  input  in  the  solution  control  packet.  CASE  contains 
the  case-dependent  parameters,  JOE  contains  the  case-independent  requests 
and  OPTIMIZE  contains  the  optimization-dependent  requests. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CBAR 

Relation 

Contains  the  element  connectivity  data  for  the  BAR  element  as  input  from  the 
Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

PID1 

Integer  >  0 

Property  identification  number  of  a  PBAR 
tuple 

GRID1 

Integer  >  0 

Grid  point  identification  for  end  A 

GRID2 

Integer  >  0 

Grid  point  identification  for  end  B 

GRID3 

Integer  >  0 

Grid  point  identification  for  orientation 
vector  definition 

ORIENTX 

Real 

Orientation  vector 

ORIENTY 

Real 

ORIENTZ 

Real 

TMAX 

Real 

Maximum  area  for  design 

PINA 

Integer  >  0 

Components  pinned  at  end  A 

PINB 

Integer  >  0 

Components  pinned  at  end  B 

OFFSETAX 

Real 

Offsets  from  GRID1  and  GRID2  to  the 
ends  of  the  beam  element 

OFFSETAY 

Real 

OFFSETAZ 

Real 

OFFSETBX 

Real 

OFFSETBY 

Real 

OFFSETBZ 

Real 

Module  IFP 


1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  BEAMEST  relation. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CELAS1 

Relation 

Contains  the  element  connectivity  data  for  the  scalar  spring  element  as  input 
from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0 

Element  identification  number 

PID1 

Integer  >  0 

Identification  number  of  a  PELAS  property 
entry 

GRID1 

Integer  >  0 

Grid  or  scalar  point  identification  number 

COMPNTS1 

6  >  Integer  >  0 

Component  number 

GRID2 

Integer  >  0 

Grid  or  scalar  point  identification  number 

COMPNTS2 

6  2  Integer  >  0 

Component  number 

TMAX 

Real 

Maximum  spring  constant  value  for  design 

Module  IFP 

1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  ELASEST  relation. 
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Entity: 

Entity  'type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CELAS2 

Relation 

Contains  the  element  connectivity  and  piopcrty  data  for  the  scalar  spring  ele¬ 
ment  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0 

Element  identification  number 

K 

Real 

The  value  of  the  scalar  spring  constant 

GRID1 

Integer  >  0 

Grid  or  scalar  point  identification  number 

COMPNTS1 

6  >  Integer  >  0 

Component  number 

GRID2 

Integer  >  0 

Grid  or  scalar  point  identification  number 

COMPNTS2 

6  >  Integer  >  0 

Component  number 

DAMPCOEF 

Real 

Damping  coefficient 

STRSCOEF 

Real 

Stress  coefficient 

TMIN 

Real 

Minimum  spring  constant  value  for  design 

TMAX 

Real 

Maximum  spring  constant  value  for  design 

Module  IFP 

1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  ELASEST  relation. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CIHEX1 

Relation 

Contains  the  element  connectivity  data  for  the  linear  isoparametric  hexahedron 
element  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

PID 

Integer  >  0 

Identification  number  of  property  card 

GRID1,  GRID2 

Integer  >  0 

Grid  point  identification  numbers 
defining  the  element  geometry 

GRID3,  GRID4 

Integer  >  0 

GRID5,  GRID6 

Integer  >  0 

GRID7,  GRID 8 

Integer  >  0 

Module  IFP 


1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  EHEX1EST  rela¬ 
tion. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CIHEX2 

Relation 

Contains  the  element  connectivity  data  for  Lhe  quadratic  isoparametric  hexahe¬ 
dron  element  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

PID 

Integer  >  0 

Identification  number  of  property 
card 

GRID1,  GRID2 

Integer  >  0 

Grid  point  identification  numbers 
defining  the  element  geometry 

GRTD3,  GRID 4 

Integer  >  0 

GRID5,  GRID6 

Integer  >  0 

GRID7 ,  GRID 8 

Integer  >  0 

GRID9,  GRIDIO 

Integer  >  0 

GRID11,  GRID12 

Integer  >  0 

GRID13,  GRID14 

Integer  >  0 

GRID15,  GRID16 

Integer  >  0 

GRID17,  GRID18 

Integer  >  0 

GRID19,  GRID20 

Integer  >  0 

Module  IFP 


1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  IHEX2EST  rela¬ 
tion. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CIHEX3 

Relation 

Contains  the  element  connectivity  data  for  the  cubic  isoparametric  hexahedron 
element  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

PID 

Integer  >  0 

Identification  number  of  property 
card 

GRID1,  GRID2 

Integer  >  0 

Grid  point  identification  numbers 
defining  the  element  geometry 

GRID3,  GRID4 

Integer  >  0 

GRIDS,  GRID 6 

Integer  >  0 

GRID7,  GRID 8 

Integer  >  0 

GRID9,  GRID10 

Integer  >  0 

GRID11,  GRID12 

Integer  >  0 

GRID13,  GRID14 

Integer  >  0 

GRID15,  GRID16 

Integer  >  0 

GRID17,  GRID18 

Integer  >  0 

Grid  point  identification  numbers 
defining  the  element  geometry 

GRID19,  GRID20 

Integer  >  0 

GRID21,  GRID22 

Integer  >  0 

GRID23,  GRID24 

Integer  >  0 

GRID25,  GRID26 

Integer  >  0 

GRID27 ,  GRID28 

Integer  >  0 

GRID29,  GRID30 

Integer  >  0 

GRID31,  GRID32 

Integer  >  0 

Module  IFP 


1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  IHEX3EST  rela¬ 
tion. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CLAMBDA 

Relation 

Contains  results  of  a  flutter  analysis  for  a  series  of  boundary  conditions,  Msch 
numbers  and  atmospheric  densities. 


NAME 

TYPE/KEY 

DESCRIPTION 

NITER 

Integer 

Iteration  number 

BCID 

Integer 

The  boundary  condition  number 

MACH 

Real 

Mach  number  of  the  flutter  analysis 

RHOREF 

Real 

Reference  atmospheric  density 

RHO 

Real 

Atmospheric  density  of  the  flutter  analysis 

VELOCITY 

Real 

True  velocity  of  the  flutter  analysis 

FSID 

Integer 

Flutter  set  identification 

SCNUM 

Integer 

Flutter  subcase  identification  number 

MODENO 

Integer 

Mode  number  associated  with  the  flutter 

RLAMB 

Real 

Real  part  of  the  flutter  eigenvalue 

I  LAMB 

Real 

Imaginary  part  of  the  flutter  eigenvalue 

DAMPVAL 

Real 

Damping  ratio 

OMEGA 

Real 

Frequency  in  radians  per  second  of  the  flutter 
eigenvalue 

=  2  *  VELOCITY  *  ILAMB  /  REFB 

PNUM 

Integer 

Pointer  to  CONST  tuple  for  the  associated 
constraint 

Module  FLUTTRAN 

1.  The  reference  semichord  for  the  unsteady  area  model  is  stored  as  the  elev¬ 
enth  word  of  the  INFO  array. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CMASS1 

Relation 

Contains  the  element  connectivity  data  for  the  scalar  mass  element  as  input  from 
the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

PID1 

Integer  >  0 

Property  identification  number  of  a 

PMASS  tuple 

GRID1 

Integer  >  0 

Grid  or  scalar  point  identification  number 

COMPNTS 1 

Integer  >  0 

Component  of  GRID1  to  which  the  element 
is  connected 

GRID2 

Integer  >  0 

Grid  or  scalar  point  identification  number 

COMPNTS 2 

Integer  >  0 

Component  of  GRID2  to  which  the  element 
is  connected 

TMAX 

Real 

Maximum  mass  for  design 

Module  IFF 

1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  MASSEST  relation. 
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Entity: 

Entity  Type- 
Description: 

Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


CMASS2 

Relation 

Contains  the  element  connectivity  data  for  the  scalar  mass  element  as  input  from 
the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

MASS 

Real 

The  value  of  the  scalar  mass 

GRID1 

Integer  >  0 

Grid  or  scalar  point  identification  number 

COMPNTS1 

Integer  >  0 

Component  of  GRID1  to  which  the  element 
is  connected 

GRID2 

Integer  >  0 

Grid  or  scalar  point  identification  number 

COMPNTS2 

Integer  >  0 

Component  of  GRID2  to  which  the  element 
is  connected 

TMIN 

Real 

Minimum  mass  for  design 

TMAX 

Real 

Maximum  mass  for  design 

Module  IFF 

1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  MASSEST  relation. 

CONEFFF 

Relation 

Contains  the  definition  of  adjustment  factors  for  control  surface  effectiveness  val¬ 
ues  for  use  in  flutter  analysis. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Effectiveness  identification  number 

EFFVAL 

Real 

Effectiveness  value 

MODE 

Integer  >  0 

Structural  mode  to  which  the  effectiveness  is  to 
be  applied 

MACRO ID 

Integer 

aerodynamic  component  (macroelement)  on 
which  the  control  surface  lies 

BOX1,  BOX2 

Integer  >  0 

First  and  last  box  whose  effectiveness  is  to  be 
altered 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


CONEFFS 

Relation 

Contains  the  definition  of  adjustment  factors  for  control  surface  effectiveness  val¬ 
ues  for  use  in  static  aeroelastic  analysis  and  nonplanar  aerodynamic  analysis. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Effectiveness  identification  number 

LABELI 

Tfext  (8) 

Control  surface  label 

EFFI 

Real 

Effectiveness  value  for  the  associated  surface 

Module  IFP 

CONLINK 

Relation 

Contains  the  control  surfaces  and  participation  factors  specified  on  the  CON- 
LINK  Bulk  Data  entry. 


NAME 

TYPE/KEY 

DESCRIPTION 

LABEL 

Tfext  (8) 

Label  of  the  control  surface  that  is  made  up  of 
a  combination  of  other  conatro  surfaces 

LABELI 

Tfext  (8) 

Label  of  control  surface  defined  by  AESURF 

VALUEI 

Real 

Participation  factor 

Module  IFP 
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Entity: 

Entity  T^pe: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CONM1 

Relation 

Contains  the  element  data  for  a  8  x  6  symmetric  mass  matrix  at  a  grid  point  as  in¬ 
put  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

GRID1 

Integer  >  0 

Grid  point  identification  number 

CID1 

Integer  >  0 

Coordinate  system  identification 
number  for  matrix  coordinate  system 

Mil,  M21,  M22 

Real 

Elements  of  the  6x6  symmetric  mass 
matrix 

M31,  M32,  M33 

Real 

M41,  M42,  M43 

Real 

M44 

Real 

M51,  M52,  M53 

Real 

M54,  M55 

Real 

M61,  M62,  M63 

Real 

M64,  M65,  M66 

Real 

Module  IFP 


1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  CONM1EST  rela¬ 
tion. 


440 


Entity: 

Entity 'type : 
Description. 

Relation  Attributes: 


Created  By: 
Notes: 


CONM1EST 

Relation 

Contains  the  element  summary  data  for  a  concentrated  mass  defined  in  the 
CONM1  relation. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

SIL1 

Integer  >  0 

Internal  grid  point  identification 
number 

CIDMftSS 

Integer  >  0 

Coordinate  system  identification 
number  for  matrix  coordinate  system 

Mil,  M21,  M2 2 

Real 

Elements  of  the  6x6  symmetric  mass 
matrix 

M31,  M32,  M3 3 

Real 

M41,  M42,  M43 

Real 

M44 

Real 

M51,  M52,  M53 

Real 

M54,  M55 

Real 

M61,  M62,  M63 

Real 

M64,  M65,  M66 

Real 

CORD1 

Integer  >  0 

Coordinate  system  of  SIL1 

X,  Y,  Z 

Real 

Basic  coordinates  of  SIL1 

Module  MAKEST 


1.  This  relation  is  built  from  the  CONM1  and  grid  relations.  It  contains  one  tu¬ 
ple  for  each  concentrated  mass  element  defined  in  the  CONM1  relation. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CONM2 

Relation 

Contains  the  element  data  for  a  concentrated  mass  at  a  structural  grid  point  as 
input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

GRID1 

Integer  >  0 

Grid  point  identification  number 

CID1 

Integer 

Coordinate  system  identification 
number 

MASS 

Real 

Value  of  the  concentrated  mass 

XI,  X2,  X3 

Real 

Components  of  offset  from  GRID  I 
to  the  mass 

Ill,  121,  122 

Real 

Mass  moments  of  inertia 

131,  132,  133 

Real 

TMIN 

Real 

Minimum  mass  for  design 

TMAX 

Real 

Maximum  mass  for  design 

Module  IFP 

1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  CGNM2EST  rela¬ 
tion. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CONM2EST 

Relation 

Contains  the  element  summary  data  for  a  concentrated  mass  element  defined  in 
the  CONM2  relation. 


NAfriE 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

SIL1 

Integer  >  0 

Internal  grid  point 
identification  number 

Cl DMAS 3 

Integer  >  0 

Coordinate  system 
identification  number 

MASS 

Real 

Mass  value 

OFFSETX 

Real 

Offsets  from  SIL1  to  mass  (see 
note  1) 

OFFSETY 

Real 

OFFSETZ 

Real 

Ill,  121,122 

Real 

Mass  moments  of  inertia  (see 
Note  1) 

131,  132,  133 

Real 

COORD1 

Integer  >  0 

Displacement  coordinate 
system  for  SIL1 

X,  Y,  Z 

Real 

Basic  coordinates  of  SIL1 

DESIGN 

_ _ _ 

Integer 

Design  flag 

Module  MAKEST 


1.  Refer  to  the  CONM2  Bulk  Data  Entry  for  further  details  on  the  definition  of 
the  OFFSET  and  Iij  terms. 

2.  This  relation  is  built  from  the  CONM2  grid  relations.  It  contains  one  tuple  for 
each  concentrated  mass  element  defined  in  the  CONM2  relation. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CONROD 


Relation 

Contains  the  connectivity  and  property  data  for  a  ROD  element  as  input  from  the 
Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION  | 

EID 

Integer  >  0,  key 

Element  identification  number  j 

GRID1 

Integer  >  0 

Grid  point  identification  number  for  end  A  1 

GRID2 

Integer  >  0 

Grid  point  identification  number  for  end  B  j 

MIDI 

Integer  >  0 

I 

Material  property  identification  number 

AREA 

Real  >0 

Element  cross-sectional  area 
- -  <  “1 

TORSION 

Real  >  0 

Element  torsional  constant 

STRSCOEF 

Real 

•Stress  recovery  factor 

NSM 

Real  >  0 

Element  ncnstructural  mass 

TMIN 

Real  5  0 

Minimum  cross-sectional  area  in  design 

TMAX 

Real  S  0 

Maximum  cross-sectional  area  in  design  j 

Module  IFP 

1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  RODSST  relation. 
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Entity:  CONST 

Entity  Type:  Relation 

Description:  Contains  the  constraint  values  and  constraint  sensitivity  processing  data  for  the 

current  design  iteration. 

Relation  Attributes: 


NAME 

- — H 

TYPE/KEY 

DESCRIPTION 

NITER 

Integer  >  0 

Iteration  number 

OVAL 

Real 

Constraint  value 

CTYPE 

Integer  >  0 

Constraint  type  (see  Note  2  below) 

BCID 

Integer  >  0 
or  NULL 

Boundary  condition  identification  number  for 
constraint  value  if  boundary  condition 
dependent 

Non-boundary  dependent  constraints  are: 
minimum  thickness  (CTYPE=1) 
maximum  thickness  (CTYPE=2) 

DISFLAG 

Integer  >  0 
or  NULL 

Discipline  type  flag  from  CASE  relation  (where 
appropriate) 

Non-discipline  dependent  constraints  are: 
minimum  thickness  (CTYPE=1) 
maximum  thickness  (CTYPE=2) 
laminate  composition  (CTYPE=13) 
laminate  min.  gauge  (CTYPE=14) 
ply  min.  gauge  (CTYPE=16) 

ACTVFLAG 

Integer  ^  0 
or  NULL 

Flag  denoting  status  of  the  constraint  as  active 
(=1)  or  inactive  (=0) 

ACTVFLAG  will  have  NULL  value  prior  to 
constraint  screening  in  ACTCON 

SCRUM 

Integer  >  0 
or  NULL 

See  Remark  11 

S-NUM 

Integer  >  0 
or  NULL 

See  Remark  12 

SUB5CRPT 

Integer  >  0 
or  NULL 

Subscript  number  for  SAERO  discipline 
constraints  of  types  3, 4,  5,  6,  9, 10, 11,  and  12 

DI SPOOL 

S 

Integer  >  0 
or  NULL 

Column  number  in  the  matrix  of 
pseudodieplacements/accelerations  for  static 
aeroelastic  constraints  ot  types  9, 10,  and  12 

ETYPE 

Text  (8)  or 
NULL 

Element  type  used  for  stress/strain  and 
thickness  constraints 

SID 

Integer  or 
NULL 

Element  identification  number 

LAYERNUM 

Integer  or 
NULL 

Element  layer  information  (See  Remark  14) 

5  COR 

Integer  >  0 
or  NULL 

See  Remark  13 
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NAME 

TYPE/KEY 

r~“ —  ~~1 

DESCRIPTION  ) 

VS  CON 

Real  vector(6) 

Allowables  for  stress/strain  constraints  I 

SENSPRM1 

Real 

General  values  useful  for  sensitivity 
calculations  (see  Remark  10) 

SENSPRM2 

Real 

SENSPBM3 

Real 

SENSPRm 

Text (8) 

PRINTKEY 

Integer 

Pointer  to  the  GRADIENT  entity  containing 
the  gradient  of  the  constraint  with  respect  to 
the  global  variables 

=  0  if  no  gradient  was  stored  (see  Remark  15) 

Created  By:  See  Note  below. 

Notes: 

1.  NULL  values  imply  the  value  is  supplied  with  the  database  default  null 
value.  These  are  typically  bit  patterns  which  represent  illegal  values  of  their 
respective  data  types.  See  RENULi  utility  documentation.  For  this  relation, 
zero  is  sometimes  used  in  place  of  the  database  NULL  value. 

2.  The  constraint  types  are: 

0  =  Objective  function 

1  =  Minimum  thickness  constraint 

2  =  Maximum  thickness  constraint 

3  =  Displacement  constraint 

4  =  Stress  constraint 

5  =  Strain  constraint  on  Ex  principal  strain 

6  =  Strain  constraint  on  Ey  principal  strain 

7  =  Frequency  constraint 

8  =  Flutter  constraint 

9  =  Lift  Effectiveness  Constraint 

10  =  Aileron  Effectiveness  Constraint 

11  =  Trim  Parameter  Limit  Value  Constraint  (DCON  TRM) 

12  =  Stability  Derivative  Constraint  (DCONSCF) 

13  =  Laminate  Composition  Constraint  (DCONLAM) 

14  =  Laminate  Minimum  Gauge  Constraint  (DCONLMN) 

15  =  Ply  Minimum  Gauge  Constraint  (DCONPMN) 

3.  Constraints  of  Types  1  and  2  are  evaluated  in  the  TCEVAL  module.  The  sen¬ 
sitivities  are  evaluated  in  the  MAKDFV  module. 

4.  Constraints  of  Type  3  are  evaluated  in  the  DCEVAL  module.  The  sensitivi¬ 
ties  are  evaluated  in  the  MAKDFU  module. 

5.  Constraints  of  Type  4,  5  and  6  are  evaluated  in  the  SCEVAL  module.  The  sen¬ 
sitivities  are  evaluated  in  the  MAKDFU  module. 

6.  Constraints  of  Type  7  are  evaluated  in  the  FCEVAL  module.  The  sensitivities 
are  evaluated  in  the  FREQSENS  module. 

7.  Constraints  of  Type  8  are  evaluated  in  the  FLUTTRAN  module.  The  sensitivi¬ 
ties  are  evaluated  in  the  FLUTSENS  module. 

8.  Constraints  of  Types  9, 10, 11,  and  12  are  evaluated  in  the  SAERO  module. 
The  sensitivities  of  9, 10,  and  12  are  evaluated  in  the  AEROEFFS  and  those 
of  11  in  the  AEROSENS  module. 
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9.  Constraints  of  Types  13,  14,  and  15  are  evaluated  in  the  LAMINCON  module. 
The  sensitivities  are  evaluated  in  the  LAMINSNS  module. 

10.  The  SENSPRM1,  2,  3,  and  4  attributes  contain  values  useful  in  sensitivity 
analysis  for  certain  constraint  types. 

Type  1  -  SENSPRM1  contains  the  minimum  gauge  used  to  normalize 

the  constraint. 

Type  2  -  SENSPRM2  contains  the  maximum  gauge  used  to  normalize 

the  constraint. 

Type  7  -  SENSPRM1  contains  the  current  value  of  the  associated 

eigenvalue. 

TVpe  9  -  SENSPRM1  contains  the  current  value  of  the  associated  rigid 

lift  curve  slope.  SENSPRM2  contains  the  value  of  the  associ¬ 
ated  required  ratio. 

Type  10  -  SENSPRM1  contains  the  current  value  of  the  associated  di¬ 
mensional  flexible  rolling  moment  slope  due  to  aileron  deflec¬ 
tion. 

SENSPRM2  contains  the  current  value  of  the  associated  flex¬ 
ible  rolling  moment  slope  due  to  roll  rate. 

SENSPRM3  contains  the  required  roll  effectiveness  and  other 
constants: 

jb  *  180 
SENSPRM3  =  - 

2E*c 

where 

b  =  reference  span 

2 e^Q  =  required  aileron  effectiveness 

SENSPRM4  contains  the  name  of  the  rolling  control  surface 
whose  effectiveness  is  constrained. 

Type  11  -  SENSPRM1  contains  the  required  value  of  the  trim  parame¬ 
ter. 

SENSPRM4  contains  the  name  of  the  trim  parameter  whose 
derivative  is  constrained. 

Type  12  -  SENSPRM1  contains  the  required  dimensional  value  of  the 
stability  derivative. 

SENSPRM2  contains  the  real  equivalent  of  the  degree  of  free¬ 
dom  number  (1,  2, ...  or  6)  representing  the  DOF  associated 
with  the  derivative. 

SENSPRM4  contains  the  name  of  the  trim  parameter  or  accel¬ 
eration  whose  derivative  is  constrained. 

Type  13  -  SENSPRM1  contains  the  required  upper  or  lower  bound  per¬ 
centage  of  ply  to  laminate  thickness. 

SENSPRM2  contains  the  current  ply  thickness 
SENSPRM3  contains  the  current  laminate  thickness 
Type  14  -  SENSPRM1  contains  the  minimum  thickness  value. 

SENSPRM3  contains  the  current  laminate  thickness 
Type  15  -  SENSPRM1  contains  the  minimum  thickness  value. 

SENSPRM2  contains  the  current  ply  thickness 

11.  The  SCNUM  attribute  contains  general  information  to  allow  computation  of 
the  sensitivities.  These  data  are  the  following: 

Type  1  -  =  0  if  constraint  does  not  appear  on  a  DCONTHK/2  entry 
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=  1  if  it  does  appear  on  DCONTHK/2 
type  2  -  NULL 

type  3  -  Subcase  number  of  discipline  generating  the  constraint 

type  4  -  Subcase  number  of  discipline  generating  the  constraint 

type  5  -  Subcase  number  of  discipline  generating  the  constraint 

type  6  -  Subcase  number  of  discipline  generating  the  constraint 

type  7  -  Mode  number  associated  *\nth  the  constraint 

type  8  -  Subcase  number  generating  the  constraint 

type  9  -  Subcase  number  generating  the  constraint 

type  10  -  Subcase  number  generating  the  constraint 

type  11  -  Subcase  number  generating  the  constraint 

type  12  -  Subcase  number  generating  the  constraint 

type  13-  NULL 

type  14  -  NULL 

type  15  -  NULL 

12.  The  PNUM  attribute  contains  general  pointer  information  to  allow  computa¬ 
tion  of  the  sensitivities.  The  pointer  data  are  the  following: 

type  1  -  PMINT  matrix  column  number  associated  with  the  constraint 

type  2  -  PMAXT  matrix  column  number  associated  with  the  constraint 

type  3  -  Displacement  constraint  number  which  points  into  the 
DCENT  entity 

type  4  -  Row  in  GLBSIG  where  first  stress  component  for  the  element 
is  stored 

type  5  -  Row  in  GLBSIG  where  first  stress  component  for  the  element 
is  stored 

type  6  -  Row  in  GLBSIG  where  first  stress  component  for  the  element 
is  stored 

type  7  -  NULL 

type  8  -  Count  number  in  a  running  count  of  flutter  roots.  Matches 
the  PNUM  attribute  in  CLAMBDA 
type  9  -  NULL 

type  10  -  NULL 

type  11-  NULL 

type  12  -  NULL 

type  13  -  Defines  the  laminate 

=  0  if  the  lamanate  thickness  comprises  all  layers 
=  LAMSET  id  of  PLYLIST  data  if  the  lamanate 
thickness  comprises  a  subset  of  layers 
type  14  -  =0 

type  15  -  =0 

13.  The  SCON  attribute  contains  general  information  to  allow  computation  of  the 
sensitivities.  These  data  are  the  following: 

type  1  -  NULL 

type  2  -  NULL 

type  3  -  NULL 

Type  4  -  =  1  for  Von  Mises  Stress 

=  2  for  Tsai  Wu  Stress 

type  5  -  =  +3  Principal  strain  constraint  using  tension  allowable 

r  -  3  Principal  strain  constraint  using  compression  allowable 
=  +4  Fiber/transverse  strain  constraint  using  tension  allow¬ 
able 


i 
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=  -  4  Fiber/transverse  strain  constraint  using  compression  al¬ 
lowable 

Type  6  -  =  +3  Principal  strain  constraint  using  tension  allowable 

=  -  3  Principal  strain  constraint  using  compression  allowable 
=  +4  Fiber/transverse  strain  constraint  using  tension  allow¬ 
able 

=  -  4  Fiber/transverse  strain  constr  jnt  using  compression  al¬ 
lowable 

Type  7  -  UPPER  (= 1)  or  LOWER  (=-l)  bound  flag 
Type  8  -  A  combined  number  noting  the  velocity,  mode  and  subcase 

number  generating  the  constraint  of  the  form: 
xxxyyyzzz 

where  xxx  =  subcase  number 

yyy  =  mode  number 
zzz  =  velocity  number 

each  are  limited  to  999.  This  value  is  only  useful  in  that  sort¬ 
ing  by  SCON  sorts  the  constraints  by  velocity  within  each 
mode  within  each  subcase. 

Type  9-  UPPER  (=1)  or  LOWER  (=-l)  bound  flag 
Type  10  -  UPPER  (=1)  or  LOWER  (=-l)  bound  flag 

Type  11  -  UPPER  (=1)  or  LOWER  (=-l)  bound  flag 

Type  12  -  UPPER  (=1)  or  LOWER  (=-l)  bound  flag 

Type  13  -  UPPER  (=1)  or  LOWER  (=---1)  bound  flag 

Type  14  -  =0 

Type  15  -  =0 

14.  The  LAYERNUM  is  only  set  if  the  gradient  is  stored.  This 
Types  1,  4,  5,  arrdb Stains  the  layer  number  (if  applicable)  or  0 
Types  13,  and  l£->  0,  contains  the  layer  number  of  the  ply 

if  <  0,  contains  the  PLYLIST  id  of  the  set  of  layers  in  the  ply 
if  >  0,  contains  the  layer  number  of  the  ply 

15.  The  PRINTKEY  is  only  set  if  the  gradient  is  stored.  This  is  done  only  when 
the  requested  objective  and/or  constraint  fradient  is  selected  in  a  print  of 
punch  request. 
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Entity: 

Entity  Ttype: 
Description: 

Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes. 


Created  By: 
Notes: 


CONVERT 

Relation 

Contains  the  conversion  fa  /s  for  various  physical  quantity':  as  input  from  the 
Bulk  Data  file. 


NAME 

Type/KEY 

DESCRIPTION 

QUANTITY 

Ttest  (8) 

Character  string  identifying  the  physical 
quantity  whose  units  are  to  be  converted 

FACTOR 

Real 

Conversion  factor  to  be  applied 

Module  IFP 

1.  Refer  to  CONVERT  Bulk  Data  entry  for  the  valid  QUANTITY  values. 

CORD 1C 
Relation 

Contains  the  coordinate  system  definition  for  a  cylindrical  coordinate  system  as 
input  from  the  Bulk  Data  file. 


NAME 

Type/KEY 

DESCRIPTION 

CIDl 

Integer  >  0 

Coordinate  system  identification  number 

GRID1 

Integer  >  0 

The  grid  point  identification  number  which 
locates  the  system  origin 

GRID2 

Integer  >  0 

The  grid  point  identification  number  which 
defines  the  system  z-axis 

GRID3 

Integer  >  0 

The  grid  point  identification  number  which 
defines  a  point  lying  in  the  system  xz-plane 

Module  IFP 

1.  This  relation  is  used  by  the  MKTMAT  module  to  build  the  CSTM  relation. 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CORD2C 

Relation 

Contains  the  coordinate  system  definition  for  a  cylindrical  coordinate  system  as 
input  from  the  Bulk  Data  file. 


NAME 

Type/KEY 

DESCRIPTION 

C.TD1 

Integer  >  0 

Coordinate  system  identification  number 

RID 

Integer  >=0 

Coordinate  system  identification  number  of 
system  in  which  the  coordinates  of  the  defining 
locations  are  given 

Al,  A2,  A3 

Real 

Coordinates  of  system  origin 

Bl,  B2,  B3 

Real 

Coordinates  defining  z-axis 

Cl,  C2,  C3 

Real 

Coordinates  defining  xz  plane 

Module  IFP 

1.  This  relation  is  used  by  the  MKTMAT  module  to  build  the  CSTM  relation. 

CORD1R 

Relation 

Contains  the  coordinate  system  definition  for  a  rectangular  coordinate  system  as 
input  from  the  Bulk  Datafile. 


NAME 

Type/KEY 

DESCRIPTION 

CID1 

Integer  >  0 

Coordinate  system  identification  number 

GRID1 

Integer  >  0 

The  grid  point  identification  number  which 
locates  the  system  origin 

GRID2 

Integer  >  0 

The  grid  point  identification  number  which 
defines  the  system  z-axis 

GRID3 

Integer  >  0 

The  grid  point  identification  number  which 
defines  a  point  lying  in  the  system  xz-plane 

Module  IFP 

1.  This  relation  is  used  by  the  MKTMAT  module  to  build  the  CSTM  relation. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Crea'  ;d  By; 
Notes: 


CORD2R 

Relation 

Contains  the  coordinate  system  definition  for  a  rectangular  coordinate  system  as 
input  from  the  Bulk  Data.  file. 


NAME 

Type/KEY 

DESCRIPTION 

CID1 

Integer  >  0 

Coordinate  system  identification  number 

RID 

Integer  >  0 

Coordinate  system  identification  number  of 
system  in  which  the  coordinates  of  the  defining 
locations  are  given 

Al,  A2,  A3 

Real 

Coordinates  of  system  origin 

Bl,  B2,  B3 

Real 

Coordinates  defining  z-axis 

Cl,  C2 ,  C3 

Real 

Coordinates  defining  xz-plane 

Module  IFP 

1.  This  relation  is  used  by  the  MKTMAT  module  to  build  the  CSTM  relation. 

CORDIS 

Relation 

Contains  the  coordinate  system  definition  for  a  spherical  coordinate  system  as  in 
put  from  the  Bulk  Data  file. 


NAME 

— 

Type/KEY 

DESCRIPTION 

CID1 

Integer  >  0 

Coordinate  system  identification  number 

GRID1 

Integer  >  0 

The  grid  point  identification  number  which 
locates  the  system  origin 

GRID2 

Integer  >  0 

The  grid  point  identification  number  which 
defines  the  system  z-axis 

GRID3 

Integer  >  0 

The  grid  point  identification  number  which 
defines  a  point  lying  in  the  system  xz-plane 

Module  IFP 

1.  This  relation  is  used  by  the  MKTMAT  module  to  build  the  CSTM  relation. 
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Entity: 
Entity  Type: 
Description: 


CORD2S 

Relation 


Contains  the  coordinate  system  definition  for  a  spherical  coordinate  system  as  in¬ 
put  from  the  Bulk  Data  file. 

Relation  Attributes: 


NAME 

Type/KEY 

DESCRIPTION 

CIDl 

Integer  >  0 

Coordinate  system  identification  number 

RID 

Integer  >  0 

Coordinate  system  identification  number  of 
system  in  which  the  coordinates  of  the  defining 
locations  are  given 

Al,  A2,  A3 

Real 

Coordinates  of  system  origin 

Bl,  B2,  B3 

Real 

Coordinates  defining  z-axis 

Cl,  C2,  C3 

Real 

Coordinates  defining  xz-plane 

Module  IFP 


Created  By: 
Notes: 


1.  This  relation  is  used  by  the  MKTMAT  module  to  build  the  CSTM  relation. 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CQDMEM1 

Relation 

Contains  the  element  connectivity  data  for  the  linear  isoparametric  quadrilateral 
membrane  element  as  input  from  the  Bulk  Data  file. 


NAME 

Type/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  numbe** 

PID1 

Integer  >  0 

Property  identification  number  of  P- 
Type  tuple 

GRIDl,  GRID2 

Integer  >  0 

Grid  point  identification  number 

GRID3,  GRID 4 

Integer  >  0 

CID 

Integer  >  0 

Coordinate  system  v^eu  to  define 
material  axis 

THETA 

Red 

Material  orientation  angle  for 
anisotropic  materials 

TMAX 

Real  >0 

Maximun  element  thickness  in  design 

Module  IFP 

1.  The  PID  refers  to  a  PQDMEM1  tuple. 

2.  This  relation  is  used  by  the  MAKEST  module  to  build  the  QDMM1EST  rela¬ 
tion. 

3.  Note  that  the  relation  contains  two  attributes  CID  and  THETA  to  account  for 
the  dual  definition  of  the  THETA  field  on  the  CQDMEM1  bulk  data  entry. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CQUAD4 

Relation 

Contains  the  element  connectivity  data  for  the  quadrilateral  bending  element  as 
input  from  the  Bulk  Data  file. 


NAMF. 

Type/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

PID1 

Integer  >  0 

Property  identification  number  of  P- 
Type  tuple 

GRID1,  GRID2 

Integer  >  0 

Grid  point  identification  number 

GRIDS,  GRID4 

Integer  >  0 

CID1 

Integer  >  0 

Coordinate  system  used  to  define 
material  orientation 

THETA 

Real 

Material  orientation  angle  for 
anisotropic  materials 

OFFSETO 

Real 

Offset  of  element  reference  plane  from 
plane  of  the  grid  point 

TMAX 

Real  2  0 

Maximun  laminate  thickness  in  design 

THICK1 

Real  2  0 

Element  thickness  at  grid  point  GRID1 

THICK2 

Real  2  0 

Element  thickness  at  grid  point  GRID2 

THICK3 

Real  2  0 

Element  thickness  at  grid  point  GRID3 

THICK4 

Real  2  0 

Element  thickness  at  grid  point  GRED4 

Module  IFP 


1.  The  PID  may  refer  to  a  PCOMPi  or  PSHELL  tuple. 

2.  This  relation  is  used  by  the  MAKEST  module  to  build  the  QUAD4EST  rela¬ 
tion. 

3.  Note  that  the  relation  contains  two  attributes  CID  and  THETA  to  account  for 
the  dual  definition  of  the  THETA  field  on  the  CQUAD4  bulk  data  entry. 


455 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CROD 


Relation 

Contains  the  element  connectivity  data  for  the  ROD  element  as  input  from  the 
Bulk  Data  file. 


NAME 

Type/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

PID1 

Integer  >  0 

Property  identification  number  of  a  PROD 
tuple 

GRID1 

Integer  >  0 

Grid  point  identification  number  defining 
end  A 

GRID2 

Integer  >  0 

Grid  point  identification  number  defining 
end  B 

TMAX 

Real  ^0 

Maximum  cross-sectional  area  in  design  j 

Module  IFP 

1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  RODEST  relation. 

CSHEAR 

Relation 

Contains  the  connectivity  data  for  the  shear  panel  as  input  from  the  Bulk  Data 
file. 


NAME 

Type/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

PID1 

Integer  >  0 

Property  identification  number  of  a 
PSHEAR  tuple 

GRID1,  GRID2 

Integer  >  0 

Grid  point  identification  numbers 
defining  the  element  geometry 

GRID3,  GRID 4 

Integer  >  0 

TMAX 

Real  >0 

Maximum  thickness  in  design 

Module  IFP 

1.  This  relation  is  used  by  the  MAKEST  module  to  build  the  SHEAREST  rela¬ 
tion. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


CSTM 

Relation 

Contains  the  coordinate  transformation  matrices  for  all  external  coordinate  syS' 
terns. 


NAME 

Type/KEY 

DESCRIPTION 

CID 

Integer  >  0.  key 

Unique  coordinate  system 
identification  number 

CORDTYPE 

Integer  >  0 

The  type  of  coordinate  system 

XO,  YO  ,Z0 

Real 

Basic  coordinates  of  the  system 
origin 

Til,  T21,  T31 

Real 

Elements  of  the  3x3  orthogonal 
transformation  matrix  in  column 
order 

T12,  T22,  T32 

Real 

T13,  T23,  T33 

Real 

Created  By:  Module  MKTMAT 

Notes: 

1.  This  relation  contains  one  tuple  for  each  external  coordinate  system  in  the 
problem. 

2.  The  CORDTYPE  attribute  contains  a  value  of: 

1  —  if  the  system  is  rectangular 

2  =  if  the  system  is  cylindrical 

3  -  if  the  system  is  spherical 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


CTRIA3 

Relation 

Contains  the  connectivity  data  for  the  triangular  shell  element  es  input  from  the 
Bulk  Data  fiie. 


NAME 

Type/KEY  j  DESCRIPTION  1 

EID 

Integer  >  0,  key  j  Element  identification  number  j 

PID1 

..  .. 

Integer  >0  1  P™Perty  tuple  identification 

i  number  | 

GRID’ e  GRID2 

Integer  >  0 

r  t 

Grid  point  identification  numbers  j 

GRID3 

Integer  >  0 

defining  the  element  geometry  j 

CID1 

Integer 

Coordinate  system  used  to  define  j 
the  material  orientation  5 

THETA 

Real 

Material  orientation  angle  for  j 

anisotropic  materials  ! 

OFF3ETO 

Real 

Offset  of  element  reference  plane  f 
from  plane  of  the  grid  point  f 

TMAX 

Real  >0 

Maximum  laminate  thicknesses  at  ! 
each  grid  point  j 

THICK1 

Real  >0 

k  .  -j 

Element  thicknesses  at  each  grid  j 
point  5 

THICK2 

Real  >  0 

THICK3 

Real  >0 

Module  IFF 


1.  The  PID  may  refer  to  a  PCOMPi  or  PSHELL  tuple. 

2.  This  relation  is  used  by  the  MAKEST  module  to  build  the  TRIA3E5?  rela¬ 
tion. 

3.  Note  that  the  relation  contains  two  attributes  CID  and  THETA  in  order  to  ac¬ 
count  for  the  dual  definition  of  the  THETA  field  on  the  CTRIA3  Bulk  Data  en¬ 
try. 
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Entity: 
Entity  Type: 
Description: 


CTHMEM 

Relation 


Contains  the  connectivity  data  for  the  constant  strain  triangular  membrane  ele¬ 
ment.  as  input  from  the  Bulk  Data  file. 

Relation  Attributes: 


NAME 

Type/KEY 

DESCRIPTION 

EXD 

Integer  >  0,  key 

Element  identification  number 

PID1 

Integer  >  0 

Property  identification  number  cf  a 
PTRMEM  tuple 

GRID! 

Integer  >  0 

Grid  identification  numbers  defining  the 
geometry 

GRID2 

Integer  >  0 

GRID3 

Integer  >  0 

CID 

Integer  >  0 

Coordinate  system  used  to  define  the 
material  axis 

THETA 

Real 

Material  orientation  angle  for  anisotropic 
materials 

!  TMAX 

Real  >  0 

Maximum  thickness  in  design 

Created  By:  Module  IFP 

Notes: 

1.  This  relation  is  used  by  the  MAKE  ST  module  to  build  the  TRMEMEST  rela¬ 
tion. 

2.  Note  that  the  relation  has  two  attributes  CID  and  THETA  to  account  for  the 
dual  definition  of  the  THETA  field  on  the  CTRMSM  bulk  data  entry. 

Entity:  D 


Entity  Type: 
Description: 


Matrix  Form. 


Created  By: 
Notes: 


Subscripted  Matrix 

Contains  the  rigid  body  transformation  matrix  relating  the  displacements  of  the 
solution  set  to  those  of  the  support  set. 

A  variable  sissd  design  invariant  matrix  having  one  column  for  each  degree  of 
freedom  in  the  support  set  and  one  row  for  each  degree  of  freedom  in  the  solution 
set  for  the  current  boundary  condition. 

MAPOL 

1.  This  matrix  is  design  invariant  and  is,  therefore,  computed  only  once  for  each 
unrestrained  boundary  condition. 


Entity: 
Entity  Type: 
Description: 
Record: 


Notes: 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


DCENT 

Unstructured 

Contains  collected  displacement  constraint  information. 

1.  ID’s  of  the  NDSET  displacement  constraint  sets. 

i.  Contains  data  for  the  (i-l)th  constraint  set.  The  information  on  each  of  these 
record  is: 


WORD  # 

VARIABLE 

..  . 

DESCRIPTION 

1 

SETID 

From  DCONDSP 

2 

NDCID 

Number  of  constraints  in  this  set 

j 

DCID 

Displacement  constraint  ID 

j+1 

CTYPE 

Constraint  type  (see  Remark  4) 

j+2 

ALLOWD 

Allowable 

j+3 

NTERMS 

Number  of  terms  in  the  constraint 

k 

INTID 

Internal  ID  of  constraint  component 

k+1 

AJ 

Factor  on  component 

1.  There  are  NTERMS  nested  blocks  of  k  data  for  each  block  of  j  data. 

2.  There  are  NDCED  nested  blocks  of  j  data  for  each  record. 

3.  There  are  NSET+1  records  in  the  entity. 

4.  The  constraint  type  is  either  UPPER  bound  (CTYPE=1)  or  LOWER  bound 
(CTYPE=-1). 

DCONALE 

Relation 

Contains  the  roll  effectiveness  constraint  definition  as  input  from  the  Bulk  Data 
file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Aerodynamic  set  identification  of  the  imposed 
constraint 

LABEL 

Ttext  (8) 

Control  surface  label 

CTYPE 

Text (8) 

Constraint  type,  either  UPPER  or  LOWER 

AEREQ 

Real 

The  required  roll  effectiveness 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 


DCONCLA 

Relation 

Contains  the  flexible  lift  curve  slope  constraint  definition  as  input  from  the  Bulk 
Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SET1D 

Integer 

Aerodynamic  set  identification  of  the  imposed 
constraint 

CTYPE 

Tfext  (8) 

Constraint  type,  either  UPPER  or  LOWER 

CLAREQ 

Real 

The  required  flexible  lift  curve  slope  ratio 

Module  IFP 

DCONDSP 

Relation 

Contains  the  design  displacement  constraint  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Constraint  set  identification  number 

DCID 

Integer  >  0 

Constraint  identification  number 

CTYPE 

Tfext  (8) 

Constraint  type,  either  UPPER  or 
LOWER 

ALLOWD 

Real 

Allowable  displacement 

LABEL 

Tfext  (8) 

User  defined  label 

GRIDI 

Integer  >  0 

Grid  point  id  to  which  constraint  is 
applied 

COMPNTI 

Integer  1,2, 3, 4, 5  or  6 

Component  of  GRIDI 

AJ 

Real 

Constraint  coefficient 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


DCONEP 

Relation 

Contains  the  principle  strain  constraint  definition  by  specifying  the  identification 
numbers  of  constrained  elements. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Strain  constraint  set  identification  number 

ST 

Real 

Principle  strain  limit  in  tension 

SC 

Real 

Principle  strain  limit  in  compression 

SS 

Real 

Principle  strain  limit  in  shear 

ETYPE 

Text  (8) 

Element  type 

LAYRNUM 

Integer 

Layer  number  of  a  composite  element 

EID 

Integer  >  0 

Element  identification  number 

Module  IFP 

D CONE PM 
Relation 

Contains  the  principle  strain  constraint  definition  by  specifying  the  material  iden¬ 
tification  numbers. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Strain  constraint  set  identification  number 

ST 

Real 

Principle  strain  limit  in  tension 

SC 

Real 

Principle  strain  limit  in  compression 

SS 

Real 

Principle  strain  limit  in  shear 

MID 

Integer  >  0 

Material  identification  number 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


DCONEPP 

Relation 

Contains  the  principle  strain  constraint  definition  by  specifying  the  element  prop¬ 
erty  identification  numbers 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Strain  constraint  set  identification  number 

ST 

Real 

Principle  strain  limit  in  tension 

SC 

Real 

Principle  strain  limit  in  compression 

ss 

Real 

Principle  strain  limit  in  shear 

PTYPE 

'Ibxt  (8) 

Property  type 

LAYRNUM 

Integer 

Layer  number  of  a  composite  element 

PID 

Integer  >  0 

Property  identification  number 

Module  IFP 

DCONFLT 

Relation 

Contains  the  definition  of  the  flutter  constraint  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

GFACT 

Real  >  0.0 

Constraint  definition  scaling  factor 

VTYPE 

Tfext(8) 

Tsxt  string  identifying  the  velocity  type  for  the 
table 

=  TRUE  for  true  velocities 
=  EQUTV  for  equivalent  velocities 

VI 

Real  >0.0 

Velocity  value 

GAMAI 

Real 

Damping  value 

Module  IFP 


1.  The  relation  contains  one  tuple  for  each  velocity,  damping  pair  given  in  the 
Bulk  Data. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


DCONFRQ 

Relation 

Contains  the  frequency  constraint  definition  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Aerodynamic  set  identification  of  the  imposed 
constraint 

MODE 

Integer  >  0 

Mode  number  of  the  frequency  to  be 
constrained 

CTYPE 

Tfext  (8) 

Constraint  type  either  UPPER  or  LOWER 

FRQALL 

Real  >  0.0 

The  frequency  constraint  value 

Module  IFP 

DCONFT 

Relation 

Contains  the  fiber/transverse  strain  constraint  definition  by  specifying  the  identi¬ 
fication  numbers  of  constrained  elements. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Strain  constraint  set  identification  number 

EFT 

Real  >  O.u 

Tensile  strain  limit  in  the  fiber  direction 

EFC 

Real 

Compressive  strain  limit  in  the  fiber 
direction 

ETT 

Real  >  0.0 

Tensile  strain  limit  in  the  transverse 
direction 

ETC 

Real 

Compressive  strain  limit  in  the  transverse 
direction 

ETYPE 

Ttext  (8) 

Element  type 

LAYRNUM 

Integer 

Layer  number  of  a  composite  element 

EID 

Integer  >  0 

Element  identification  number 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


DCONFTM 

Relation 

Contains  the  fiber/transverse  strain  constraint  definition  by  specifying  the  mate¬ 
rial  identification  numbers. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Strain  constraint  set  identification  number 

EFT 

Real  >  0.0 

Tfensile  strain  limit  in  the  fiber  direction 

EFC 

Real 

Compressive  strain  limit  in  the  fiber 
direction 

ETT 

Real  >  0.0 

Ttensile  strain  limit  in  the  transverse 
direction 

ETC 

Real 

Compressive  strain  limit  in  in  the 
transverse  direction 

MID 

Integer  >  0 

Material  identification  number 

Module  IFP 

DCONFTP 

Relation 

Contains  the  fiber/transverse  strain  constraint  definition  by  specifying  the  ele¬ 
ment  property  identification  numbers. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Strain  constraint  set  identification  number 

EFT 

Real  >  0.0 

Tfensile  strain  limit  in  the  fiber  direction 

EFC 

Real 

Compressive  strain  limit  in  the  fiber 
direction 

ETT 

Real  >  0.0 

Ttensile  strain  limit  in  the  transverse 
direction 

ETC 

Real 

Compressive  strain  limit  in  in  the 
transverse  direction 

PTYPE 

Tfext(8) 

Property  type 

LAYRNUM 

Integer 

Layer  number  of  a  composite  element 

PID 

Integer  >  0 

Property  identification  number 

Module  IFP 
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Entity: 

Entity  T^pe: 
Description: 
Relation  Attributes: 


Created  By: 


DCONLAM 

Relation 

Contains  the  laminate  composition  constraints  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

CTYPE 

Tfext  (8) 

Constraint  type,  either  UPPER  or 
LOWER 

PERCENT 

Real 

Percent  allowable  ply  thickness 

PLYNUM 

Integer  >  0  or  •  1 

Ply  number  or  -1  if  PLYSET  is  used 

PLYSET 

Integer  >  0  or  -1 

PLYLIST  identification  number  or  -1  if 
PLYNUM  is  used 

LAMCHAR 

Ttext  (8) 

The  string  ALL  or  blank  if  LAMSET  is 
used 

LAMSET 

Integer  =  0 

PLYLIST  identification  number  or  0  if 
LAMCHAR=ALL 

SID 

Integer  >  0 

ELEMLIST  set  identification  number 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


DCONLIST 

Relation 

Contains  the  definition  of  the  constraint  lists  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

CTYPE 

Ifext  (8) 

Constraint  type  identifier 

NRFAC 

Real 

Retention  factor  for  minimum  number  of 
constraints 

EPS 

Real 

Lower  bound  value  for  constraint  selection 
by  value 

Module  1FP 

DCONLMN 

Relation 

Contains  the  laminate  minimum  gauge  constraints  as  input  from  the  Bulk  Data 
file. 


NAME 

TYPE/KEY 

DESCRIPTION 

MINTHK 

Real  >  0.0 

Allowable  minimum  gauge 

LAMCHAR 

Ttext  (8) 

The  string  ALL  or  blank  if  LAMSET  is 
used 

LAMSET 

Integer  =  0 

PLYLIST  identification  number  or  0  if 
LAMCHAR=ALL 

SID 

Integer  >  0 

ELEMLIST  set  identification  number 

SIDEONLY 

Integer  =  1  or  NULL 

If  1,  SIDEONLY  indicates  that  this 
constraint  is  redundant  with  a  side 
constraint. 

Module  IFP 
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Entity: 

Entity  Ttype: 
Description: 
Relation  Attributes: 


Created  By: 

Entity: 

Entity  T^pe: 
Description: 

Relation  Attributes: 


Created  By: 


DCONPMN 

Relation 

Contains  the  ply  minimum  gauge  constraints  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

MINTHK 

Real  >  0.0 

Allowable  minimum  gauge 

PLYNUM 

Integer  >  0  or  -1 

Ply  number  or  -1  if  PLYSET  is  used 

PLYSET 

Integer  >  0  or -1 

PLYLIST  identification  number  or  -1  if 
PLYNUM  is  used 

SID 

Integer  >  0 

ELEMLIST  set  identification  number 

SIDEONLY 

Integer  =  1  or  NULL 

If  1,  SIDEONLY  indicates  that  this 
constraint  is  redundant  with  a  side 
constraint. 

Module  IFP 


DCONSCF 

Relation 

Contains  the  definition  of  a  constraint  on  the  flexible  stability  derivative  at  the 
reference  grid  point  associated  with  the  force  or  moment  due  to  a  trim  parameter 
or  control  surface  deflection  of  the  form. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Constraint  set  identification 

ACCLAB 

Ttext  (8) 

Structural  acceleration  label 

PRMLAB 

Ttext  (8) 

Constrained  control  surface  label  or 
aeroelastic  trim  parameter 

CTYPE 

Ttext  (8) 

Constraint  type 

PRMREQ 

Real 

Stability  coefficient  bounds 

UNITS 

Tfext  (8) 

Stability  coefficient  units 

Module  IFP 
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Entity: 

Entity  'type: 
Description: 

Relation  Attributes: 


Created  By: 


DCONTH2 

Relation 

Contains  the  list  of  layers  of  composite  elements  for  which  thickness  constraints 
are  always  to  be  retained  in  optimization  with  shape  function  design  variable 
linking  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

ETYPE 

Tbxt  (8) 

Element  type.  One  of  the  following: 

QUAD4  QDMEM1 

TRIA3  TRMEM 

PLYNUM 

Integer  >  0 
or  -1 

Ply  number  or  -1  indicating  PLYSET  is  used 

PLYSET 

Integer  >  0 
or-1 

PLYLIST  set  identification  or-1  indicating 
PLYNUM  is  used 

EID 

Integer  >  0 

Element  identification  number 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 


nCONTHK 

Relation 

Contains  the  list  of  elements  for  which  thickness  constraints  are  always  to  be  re¬ 
tained  in  optimization  with  shape  function  design  variable  linking  as  input  from 
the  Bulk  Data  file. 


ftAME 

TYPE/KEY 

DESCRIPTION 

ETYPE 

Ttext  (8) 

Element  type.  One  of  the  following: 

BAR  QUAD4 

ELAS  ROD 

MASS  SHEAR 

QDMEMl  TRIAS 

TRMEM 

EID 

Integer  >  0 

Element  identification  number 

Module  IFP 


DCONTRM 

Relation 

Contains  the  definitions  of  a  trim  parameter  constraint. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Constraint  set  identification 

PPM  LAB 

Ttext  (8) 

Constrained  control  surface  label  or 
aeroekstic  trim  parameter 

CTYPE 

Itext  (8) 

Const,  ah  it  type 

FRMREQ 

Real 

Trim  parameter  bound 

Module  IFP 


470 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


DCONTW 

Relation 

Contains  the  Tsai- Wu  stress  constraint  definition  by  specifying  the  identification 
numbers  of  constrained  elements. 


— - 

NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Stress  constraint  set  identification 

XT 

Real  >  0.0 

Thnsile  stress  limit  in  the  longitudinal 
direction 

XC 

Real 

Compressive  stress  limit  in  the 
longitudinal  direction 

YT 

Real  >  0.0 

Ifensile  stress  limit  in  the  transverse 
direction 

YC 

Real 

Compressive  stress  limit  in  the  transverse 
direction 

SS 

Real  >  0.0 

Shear  stress  limit  for  in-plane  stress 

F12 

Real 

Tsai-Wa  interaction  term 

ETYFE 

Ibxt  (8) 

Element  type 

LAYRNUM 

Integer 

Layer  number  of  a  composite  element 

EID 

Integer  >  0 

Element  identification  number 

Module  IFP 
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Entity: 

Entity  'Type: 
Description: 

Relation  Attributes: 


Created  By: 


DCONTWM 

Relation 

Contains  the  Tsai-Wu  stress  constraint  definition  by  specifying  the  material  iden¬ 
tification  numbers. 


NAME 

TYPE/KEY 

DESCRIP  HON 

SETID 

Integer  >  0 

Stress  constraint  set  identification 

XT 

Real  >  0.0 

Tfensile  stress  limit  in  the  longitudinal 
direction 

XC 

Real 

Compressive  stress  limit  in  the 
longitudinal  direction 

YT 

Real  >  0.0 

Tensile  stress  limit  in  the  transverse 
direction 

YC 

Real 

i 

Compressive  stress  limit  in  the  transverse  i 
direction  t 

SS 

Real  >  0.0 

Shear  stress  limit  for  in-plane  stress  [ 

F12 

Real 

Tsai-Wu  interaction  term  1 

MID 

Integer  >  0 

Material  identification  number  j 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


DCONTWP 

Relation 

Contains  the  Tsai-Wu  stress  constraint  definition  by  specifying  the  element  prop¬ 
erty  identification  numbers. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Stress  constraint  set  identification 

XT 

Real  >  0.0 

Tensile  stress  limit  in  the  longitudinal 
direction 

XC 

Real 

Compressive  stress  limit  in  the 
longitudinal  direction 

YT 

Real  >  0.0 

Tensile  stress  limit  in  the  transverse 
direction 

YC 

Real 

Compressive  stress  limit  in  the  transverse 
direction 

SS 

Real  >  0.0 

Shear  stress  limit  for  in-plane  stress 

F12 

Real 

Tsai-Wu  interaction  term 

PTYPE 

Tfext  (8) 

Property  type 

LAYRNUM 

Integer 

Layer  number  of  a  composite  element 

PID 

Integer  >  0 

Property  identification  number 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  3y: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


DCONVM 

Relation 

Contains  the  Von-Mises  stress  constraint  definition  by  specifying  the  identifica¬ 
tion  numbers  of  constrained  elements. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Stress  constraint  set  identification  number 

ST 

Real 

Stress  limit  in  tension 

SC 

Real 

Stress  limit  in  compression 

SS 

Real 

Stress  limit  in  shear 

ETYPE 

Tbxt  (8) 

Element  type 

LAYRNUM 

Integer 

Layer  number  of  a  composite  element 

EID 

Integer  >  0 

Element  identification  number 

Module  IFP 

DCONVMM 

Relation 

Contains  the  Von-Mises  stress  constraint  definition  by  specifying  the  material 
identification  numbers. 


- . - 

NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Stress  constraint  set  identification  number 

ST 

Real 

Stress  limit  in  tension 

SC 

Real 

Stress  limit  in  compression 

SS 

Real 

Stress  limit  in  shear 

MID 

Integer  >  0 

Material  identification  number 

Module  IFF 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 
Entity  "type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 

Matrix  Form: 
Created  By: 


DCONVMP 

Relation 

Contains  the  Von-Mises  stress  constraint  definition  by  specifying  the  element 
property  identification  numbers. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Stress  constraint  set  identification  number 

ST 

Real 

Stress  limit  in  tension 

SC 

Real 

Stress  limit  in  compression 

SS 

Real 

Stress  limit  in  shear 

PTYPE 

Tsxt (8) 

Property  type 

LAYRNUM 

Integer 

Layer  number  of  a  composite  element 

PID 

Integer  >  0 

Property  identification  number 

Module  IFP 

DDELDV 

Matrix 

Matrix  of  sensitivities  of  the  trim  angles  to  changes  in  the  design  variables. 

The  number  of  rows  is  equal  to  the  number  of  trim  parameters  while  the  number 
of  columns  is  equal  to  the  number  of  active  flight  conditions  times  the  number  of 
design  variables. 

Module  AEROSENS 

1.  DDELDV  is  needed  only  when  the  design  task  includes  aero  elastic  trim  and 
the  flight  conditions  have  been  determined  to  be  active  by  module  ABOUND. 

2.  DDELDV  is  determined  through  the  solution  of  the  equation: 

[BHS  ]  [DDELW  ]  =  [DRBS  ] 

DELB 

Matrix 

Matrix  containing  trim  parameters  used  as  initial  conditions  in  the  nuclear  blast 
response  calculations. 

Real  matrix  with  three  rows  and  one  column. 

MAPOL 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 
Created  By: 

Entity: 

Entity  'type: 
Description: 

Matrix  Form: 

Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


DELM 

Matrix 

Matrix  containing  trim  that  precedes  a  nuclear  blast  response  calculation. 
Rectangular  matrix  with  two  rows  and  three  columns. 

MAPOL 

DELTA 

Subscripted  Matrix 

A  vector  of  trim  parameters  for  each  flight  condition. 

The  number  of  rows  is  dependent  on  the  type  of  trim  analysis  being  performed. 
The  number  of  columns  is  equal  to  the  number  of  load  conditions  being  applied 
for  the  current  Mach  number  and  boundary  condition. 

Module  SAERO 

1.  For  symmetric  analyses,  there  are  two  to  four  rows  in  DELTA,  depending  on 
the  value  of  TRMTYP  on  the  TRIM  Bulk  Data  entry. 

DESELM 

Relation 

Contains  design  variable  connection  information  uniquely  associating  one  design 
variable  to  one  element. 


NAME 

TYPE/KEY 

DESCRIPTION 

DVID 

Integer  >  0 

Design  variable  id 

EID1 

Integer  >  0 

Element  identification 

ETYPE1 

Tfext  (8) 

Element  type 

VMIN 

Real 

Minimum  value  of  design  variable 

VMAX 

Real 

Maximum  value  of  design  variable 

VALUE 

Real 

Initial  value  of  design  variable 

LAYERNUM 

Integer 

Layer  of  a  composite  material 

LABEL 

Tfext  (8) 

User  label 

Module  IFF 

1.  The  LAYERNUM  entry  identifies  the  layer  on  the  PCOMP  entry  for  the  ele¬ 
ment  defined  by  EID1  and  ETYPE1. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


DESHIST 

Relation 

Contains  information  on  the  results  of  major  iterations  in  the  design  task. 


NAME 

TYPE/KEY 

DESCRIPTION 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

OBJ 

Real 

Objective  function  value 

NFUNC 

Integer  >  0 

Number  of  function  evaluations  in  the  current 
iteration 

NGRAD 

Integers  0 

Number  of  gradient  evaluations  in  the  current 
iterations 

NCON 

Integers  0 

Number  of  constraints 

NAC 

Integers  0 

Number  of  active  constraints 

NVC 

Integers  0 

Number  of  violated  constraints 

NLBS 

Integers  0 

Number  of  active  lower  bound  side  constraints 

NUBS 

Integers  0 

Number  of  active  upper  bound  side  constraints 

CONVRGD 

Integers  0 

Convergence  flag 

Module  DESIGN 

1.  The  CONVRGD  parameter  has  the  following  definition: 
CONVRGD  MEANING 

0  Design  has  not  converged 

1  Design  has  converged 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


DESLINK 

Relation 

Contains  the  layer  thicknesses  of  undesigned  layers  of  designed  composite  ele¬ 
ments. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

Tbxt  (8) 

Element  type.  One  of  the  following: 

BAR  QDMEM1 

ELAS  QUAD4 

ROD  SHEAR 

TRIA3  TRMEM 

LAYRNUM 

Integer  =  0 

Layer  number,  =  0  if  noncomposite  element 

DVID 

Integer  >  0 

Global  design  variable  connected  to  this 
EID/LAYER 

PREF 

Real 

Design  Variable  Linking  Factor  (1.0  or  SHAPE 
Coefficient) 

MAKEST 

1.  There  is  one  entry  for  each  local  design  variable  for  each  global  design  vari¬ 
able  linked  to  it.  Basically,  this  is  a  relational  form  of  the  [PTRANS]  matrix. 


i 


478 


Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


DESVARP 

Relation 

Contains  the  properties  of  each  physically  linked  design  variable. 


NAME 

TYPE/KEY 

DESCRIPTION 

DVID 

Integer  >  0 

Design  variable  id 

LINKID 

Integer  >  0 

ELIST  or  PLIST  identification  number 

VMIN 

Real 

Minimum  value  of  the  design  variable 

VMAX 

Real 

Maximum  value  of  the  design  variable 

VALUE 

Real 

Initial  value  of  the  design  variable 

LAYERNUM 

Integer 

Layer  number  for  a  composite  element 

LAYRLST 

Integer 

PLYLIST  identification  number  for  layer  list 

LABEL 

Tfext  (8) 

User  label  to  describe  the  design 

Module  IFP 


1.  The  LAYERNUM  entry  identifies  the  single  ply  of  a  composite  element.  LAY- 
ERNUM  =  -1  if  LAYRLST  is  used. 

2.  The  LAYRLST  entry  identifies  the  list  of  plies  linked  to  the  design  variable. 
LAYRLST  =  -1  if  LAYRNUM  is  used. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


DESVARS 

Relation 

Contains  the  properties  of  shape  functi  m  linked  design  variable. 


NAME 

TYPE/KEY 

DESCRIPTION 

DVID 

Integer  >  0 

Design  variable  id 

SHAPEID 

Integer  >  0 

SHAPE  set  identification  number 

VMIN 

Real 

Minimum  value  of  the  design  variable 

VMAX 

Real 

Maximum  value  of  the  design  variable 

VALUE 

Real 

Initial  value  of  the  design  variable 

LAYERNUM 

Integer 

Layer  number  for  a  composite  element 

LAYRLST 

Integer 

PLYLIST  identification  number  for  layer  list 

LABEL 

lfext  (8) 

User  label 

Module  IFP 


1.  The  LAYERNUM  entry  identifies  the  single  ply  of  a  composite  element.  LAY- 
ERNUM  = -1  if  LAYRLST  is  used. 

2.  The  LAYRLST  entry  identifies  the  list  of  plies  linked  to  the  design  variable. 
LAYRLST  =  -1  if  LAYRNUM  is  used. 
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Entity: 
Entity  Type: 
Description: 
Matrix  Form: 


Created  By: 
Notes: 


DFDU 
Matrix 
See  Notes. 

A  variable  sized  matrix  having  one  row  for  each  structural  degree  of  freedom  and 
one  column  for  each  currently  active  constraint. 

The  order  of  the  DFDU  columns  is  as  follows  for  each  active  boundary  condition: 

(A)  The  sensitivities  of  active  displacement  constraints  for  each  active  load 
condition. 

(B)  The  sensitivities  of  each  active  stress  or  strain  constraint  in  each  active 
load  condition. 

Module  MAKDFU  or  MAPOL 


1.  For  the  Gradient  Method,  contains  the  sensitivities  of  che  currently  active 
constraints  to  the  global  displacements  for  those  constraints  that  are  func¬ 
tions  of  the  displacements. 

2.  For  the  Virtual  Load  Method,  contains  the  sum  of  the  sensitivity  of  the  design 
dependent  loads  and  the  product  of  the  design  sensitivity  stiffness  matrix  and 
the  active  displacement  vectors. 

3.  The  MAPOL  sequence  supports  the  following  partitions  of  the  DFPU  matrix 
(see  Theoretical  Manual  for  the  explicity  formation  of  these  submatrices): 


DFDU  -> 


<P 

'DFDUB 


DFDON  -» 


'? 

DFDVF 


Entity: 

DFDUF 

Entity  Type: 

Matrix 

Description: 

A  partition  of  matrix  DFDUN  (see  DFDU). 

Entity: 

DFDU 

Entity  Type: 

Matrix 

Description: 

A  partition  of  matrix  DFDUN  (see  DFDU). 
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Entity: 
Entity  'type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 
Entity  Structure: 
Record: 

Created  By: 
Notes: 


DRUG 

Matrix 

The  product  of  the  design  sensitivity  matrices  and  the  active  displacement  vec¬ 
tors. 

The  number  of  columns  is  equal  to  NAC,  the  number  of  active  subcases  times 
NDV,  the  number  of  design  variables.  The  number  of  rows  is  equal  to  the  number 
of  terms  in  the  g-set. 

MAKDVU 

1.  The  sensitivity  to  the  first  design  variable  for  all  the  active  subcases  occupies 
the  first  NAC  columns.  This  is  followed  by  columns  for  each  of  the  remaining 
design  variables  turn. 

2.  The  negative  of  the  product  is  created  in  order  to  simplify  later  matrix  opera¬ 
tions. 

DKVT 

Unstructured 

Contains  the  stiffness  design  sensitivity  matrices. 


1.  Contains  all  of  a  portion  of  the  stiffness  design  sensitivity  matrix  for  a  given 
design  variable. 

Module  EMA1 


1.  Relation  GMKCT  contains  connectivity  and  KCODE  information  which  de¬ 
fines  how  the  matrices  are  stored. 

2.  The  sensitivity  matrices  are  stored  in  the  same  precision  as  the  KGG  matrix. 

3.  The  INFO  array  contains  information  on  the  generation  of  the  mass  matrix. 


INFO(ll) 

INFO(12) 


1  Generate  the  global  mass  matrix  in  the  final  analysis 
0  Don’t  generate  the  global  mass  matrix 
1  Generate  the  global  mass  matrix  for  the  optimization. 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


DK1V 

Matrix 

An  intermediate  matrix  in  the  calculation  of  the  sensitivities  of  static  aeroelastic 
displacements. 

Rectangular  real  matrix  with  the  number  of  rows  equal  to  the  number  of  a-set  de¬ 
grees  and  the  number  of  columns  equal  to  the  number  of  active  displacement  vec¬ 
tors  times  the  number  of  design  variables. 

MAPOL 

1.  This  matrix  is  the  solution  to: 

[Xi i  j  [nnv  ]  =  [UPi  ] 


DLAGS 


Relation 

Contains  loading  information  for  a  dynamics  load  set  as  input  from  the  Bulk 
Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

DSID 

Integer  >  0 

DLAGS  set  identification  number 

LSID 

Integer  >  0 

Static  load  set  id 

TAU 

Real 

Time  delay  value 

PHASE 

Real 

Phase  lag  value 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


DLOAD 

Relation 

Contains  dynamic  loads  information  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer  >  0 

Load  set  identification  number 

SCAL 

Real 

Overall  scale  factor 

SCALI 

Real 

Scale  factor  for  this  tuple 

LOADI 

Integer  >  0 

ID  of  the  associated  TLOADi  or  RLOABi  set 
for  this  tuple 

Module  IFF 


1.  The  relation  is  used  in  the  transient  response  and/or  the  frequency  response 
module. 

DLONLY 

Relation 

Contains  loads  information  for  dynamic  response  as  input  from  the  Bulk  Data 
file. 


NAME 

TYPE/KEY 

DESCRIPTION 

DSID 

Integer  >  0 

DLONLY  set  identification  number 

POINT 

Integer  >  0 

Grid,  scalar  or  extra  point  ID 

COMP 

Integer  >  0 

Component  number 

AVAL 

Real 

Load  value 

Module  IFF 


1.  Subroutine  PREDOL  processes  DLONLY  data  and  write  them  to  the  UD- 
LOLY  entity. 

2.  COMP  is  1-6  for  grid  points  and  zero  for  extra  or  scalar  points. 
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Entity: 

Entity  'Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


DMAS 

Matrix 

Matrix  product  of  mass  design  sensitivity  matrices  and  active  acceleration  vec¬ 
tors. 

The  number  of  columns  is  equal  to  NAC,  the  /umber  of  active  subcases,  times 
NDV,  the  number  of  design  variables.  Thfi  number  of  rows  is  equal  to  the  number 
g-set  degrees  of  freedom. 

MAKDVU 


DMIG 

Relation 

Contains  the  direct  matrix  input  data  for  structural  matrices  as  defined  in  the 
Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

NAME 

TtextS 

Matrix  entity  name 

PREC 

lfext.4 

Matrix  precision 

FORM 

Tsxt8 

Matrix  form 

GCOL 

Integer 

External  point  identification  of  column  index 

CCOb 

Integer 

Grid  component  number  of  column  index 

GROW 

Integer 

External  point  id  of  row  index 

CROW 

Integer 

Grid  point  component  of  row  index 

XU 

Real 

Real  part  of  matrix  term 

YIJ 

Real 

Imaginary  part  of  matrix  term 

Module  EFP 
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Entity: 

DMU 

Entity  'type: 

Matrix 

Description. 

The  reduced  mass  sensitivity  matrix  used  in  the  calculation  of  sensitivities  of  dis 
placements  when  there  are  unrestrained  degrees  of  freedom. 

Matrix  Form: 

The  number  of  rows  is  equal  to  the  number  of  SUPPORT  degrees  of  freedom  and 
the  number  of  columns  is  equal  to  the  number  of  columns  in  DMUG. 

Created  By: 

MAPOL 

Notes: 

1.  This  matrix  is  computed  from: 

[  ZM7  ]  =  [  d  ]T  *  [  rmrz  ]  +  [  osor  ] 

Entity: 

DMUA 

Entity  type: 

Matrix 

Description: 

A  partition  of  the  DMUF  matrix  (see  DMUG). 

Entity: 

DMUF 

Entity  type: 

Matrix 

Description: 

A  partition  of  the  DMU  matrix  (see  DMUG). 
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Entity:  DMUG 


Entity  Type: 
Description: 

Matrix  Form: 


Created  By: 
Notes: 


Matrix 

Contains  the  product  of  the  mass  design  sensitivity  matrices  and  the  active  accel¬ 
eration  vectors. 

The  number  of  columns  is  equal  to  NAC,  the  number  of  active  subcases  times 
NDV,  the  number  of  design  variables.  The  number  of  rows  is  equal  to  the  number 
of  degrees  of  freedom  in  the  g-set. 

Module  MAKDVU 


1.  This  matrix  is  created  only  when  there  are  unrestrained  degrees  of  freedom. 

2.  The  sensitivity  to  the  first  design  variable  for  all  the  active  subcases  occupies 
the  first  NAC  columns.  This  is  followed  by  columns  for  each  of  the  remaining 
design  variables  in  turn. 

3.  The  negative  of  the  product  is  created  in  order  to  simplify  the  later  matrix  op¬ 
erations. 

4.  The  MAPOL  sequence  supports  the  partitions  of  the  DMUG  matrix  (see  the 
Theoretical  Manual  for  the  explicity  formation  of  these  submatrices:) 


ntoG  -> 


<p 

TMU8 


mm  -> 

LMUF 


9 

mxnr 

mao* 

man 

moR  ] 
muz  j 


*  Generated  for  Guyan  reduction  only. 


Entity: 

DMUL 

Entity  Type: 

Matrix 

Description: 

A  partition  of  the  DMUA  matrix  (see  DMUG). 

Entity: 

DMUN 

Entity  Type: 

Matrix 

Desc;  iption: 

A  partition  of  the  DMUG  matrix  (see  DMUG). 

Entity: 

DMUO 

Entity  Type: 

Matrix 

Description: 

A  partition  of  the  DMUF  matrix  (see  DMUG). 
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Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 
Entity  Structure: 
Record: 

Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 

Entity: 
Entity  Type: 
Description: 


DMUR 

Matrix 

A  partition  of  the  DMUA  matrix  (see  DMUG). 


DMVI 

Unstructured 

Contains  the  mass  design  sensitivity  matrices. 


i.  Contains  all  or  a  portion  of  the  mass  design  sensitivity  matrix  for  a  given  de¬ 
sign  variable. 

Module  EMA1 


1.  Relation  GMMCT  contains  connectivity  and  MCODE  information  which  de¬ 
fines  how  the  matrices  are  stored. 

2.  The  sensitivity  matrices  are  stored  in  the  same  precision  as  the  MGG  matrix. 

DPAV 

Matrix 

Partition  of  the  DPFV  matrix  (see  DPGV). 

DPFV 

Matrix 

Partition  of  the  DPNV  matrix  (see  DPGV). 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 


Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


DPGRVI 

Matrix 

Contains  the  gravity  loads  sensitivities  for  each  gravity  load  set  referenced  in  so¬ 
lution  control. 

A  variable-sized  matrix  having  one  row  for  each  structural  degree  of  freedom  and 
one  column  for  each  gravity  load  condition  for  each  design  variable  including  the 
zeroth  design  variable:  The  order  of  the  matrix  column  is: 

(A)  The  NGRAV  columns  for  each  gravity  load  set  for  the  zeroth  design  vari¬ 
able  in  load  set  id  order. 

(B)  The  NGRAV  columns  for  each  gravity  load  set  for  the  first  design  variable 
in  load  set  id  order,  etc. 

LODGEN 


1.  This  matrix  is  empty  if  no  gravity  loads  are  referenced  in  solution  control  or 
in  a  LOAD  Bulk  Data  entry. 

DPGV 
Matrix 
See  Notes. 

Real  rectangular  matrix  with  one  row  for  each  g-set  degree  of  freedom.  The  num¬ 
ber  of  columns  is  equal  to  the  number  of  active  subcases  times  the  number  of  de¬ 
sign  variables. 

MAPOL  or  MAKDFU 


1. 


2. 

3. 


For  the  Gradient  Method,  contains  the  right-hand  sides  for  the  sensitivity  cal¬ 
culations.  If  there  are  design  dependent  loads,  DPGV  is  the  sum  of  DPVJ  and 
DRUG.  If  there  are  no  design  dependent  loads,  DPGV  is  equivalent  to 
DRUG. 

For  the  Virtual  Load  Method,  contains  the  sensitivities  of  the  currently  active 
constraints  to  the  global  displacements. 

The  MAPOL  sequence  supports  the  following  partitions  of  the  DPVG  matrix 
(see  the  Theoretical  Manual  for  the  explicit  formation  of  these  matrices): 


DPGV 


9 

raw 


i 


DPNV 


9 


raw 


raw 


DPOV* 

DPAV 


DPAV  -> 


raw 

raw 


*  Generated  for  the  Guyan  reduction  only. 
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Entity: 

DPLV3 

Entity  Type: 

Matrix 

Description: 

Partition  of  the  DPAV  matrix  (see  DPGV). 

Entity: 

DPNV 

Entity  Type: 

Matrix 

Description: 

Partition  of  the  DPGV  matrix  (see  DPGV). 

Entity: 

DPOV 

Entity  Type: 

Matrix 

Description: 

Partition  of  the  DPFV  matrix  (see  DPGV). 

Entity: 

DPRV 

Entity  Type: 

Matrix 

Description: 

Partition  of  the  DPFV  matrix  (see  DPGV). 

Entity: 

DPTHVI 

Entity  Type: 

Matrix 

Description: 

Contains  the  thermal  loads  sensitivities  for  each  thermal  load  set  referenced  in 
the  solution  control. 

Matrix  Form: 

A  variable-sized  matrix  having  one  row  for  each  structural  degree  of  freedom  and 
one  column  for  each  thermal  load  condition  for  each  design  variable  including  the 
zeroth  design  variable.  The  order  of  the  matrix  columns  is: 

(A)  The  NTHERM  columns  for  each  thermal  load  set  for  the  zeroth  design 
variable  in  load  set  id  order. 

(B)  The  NTHERM  columns  for  each  thermal  load  set  for  the  first  design  vari¬ 
able  in  load  set  id  order,  etc. 

Created  By: 

Module  LODGEN 

Notes: 

1.  This  matrix  is  empty  if  no  thermal  loads  are  referenced  in  solution  control. 
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Entity:  DPVJ 

Entity  Type:  Matrix 

Description:  Contains  the  sensitivities  of  the  active  loads  to  the  design  variables. 

Matrix  Form:  A  variable-size  matrix  having  one  row  for  each  structural  degree  of  freedom  and 

one  column  for  each  active  load  in  the  current  active  boundary  condition.  The  or¬ 
der  of  the  columns  is  a3  follows: 

(A)  The  sensitivities  of  each  active  load  condition  in  load  condition  order  for 
the  first  design  variable. 

(B)  The  sensitivities  of  each  active  load  condition  in  load  condition  order  to  the 
second  design  variable  etc 

Created  By:  Module  DDLOAD 

Notes: 

1.  If  any  one  load  condition  in  the  current  active  boundary  condition  is  design 
dependent,  the  full  DPVJ  matrix  must  be  created  so  that  the  DPVJ  and  the 
DKUG  matrices  are  conformable. 

2.  If  no  design  depend  loads  exist  in  the  current  active  boundary  condition,  the 
matrix  is  empty. 

3.  The  DPVJ  is  currently  built  from  the  appropriate  linear  combinations  of 
DPTHVI  and  DPGRVI  columns. 

Entity:  DPI 

Entity  Type:  Matrix 

Description:  A  load  sensitivity  matrix  used  in  the  calculation  of  displacement  sensitivities 

when  there  are  unrestrained  degrees  of  freedom. 

Matrix  Form:  A  rectangular  matrix  with  the  number  of  rows  equal  to  the  number  of  degrees  of 

freedom  in  the  a-set  and  the  number  of  columns  is  equal  to  the  product  of  the 
number  of  columns  equal  the  number  of  columns  in  DPGV. 

Created  By:  MAPOL 

Notes: 

1.  DPI  is  computed  by  performing  a  ROWMERGE  on  matrix  entities  DMU  and 
DPGL. 
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Entity: 

DRHS 

Entity  Type: 

Matrix 

Description: 

Sensitivity  of  the  applied  loads  to  the  changes  in  the  design  variables  after  they 
have  been  reduced  to  the  support  set. 

Matrix  Form: 

The  number  of  rows  is  equal  to  the  number  of  degrees  of  freedom  in  the  r-set 
while  the  number  of  design  variables  times  the  number  of  active  load  cases  as  de¬ 
termined  by  the  ABOUND  module. 

Created  By: 

MAPOL 

Notes: 

1.  If  an  inertia  relief  sensitivity  analysis  is  being  per  formed,  DRHS  is  DPRV 
plus  the  transpose  of  D  times  DPLV. 

2.  If  a  static  aeroelastic  sensitivity  analysis  is  being  performed,  K21  times 

DKLV  is  subtracted  from  the  DRHS  defined  above. 

Entity: 

DTSLP 

Entity  Type: 

Matrix 

Description: 

A  matrix  used  in  the  nuclear  blast  calculation  to  compute  the  slopes  at  the  aerody¬ 
namic  panels  given  the  modal  participation  factors. 

Matrix  Form: 

Areal,  rectangular  matrix  with  the  number  of  rows  equal  to  the  number  of  aero¬ 
dynamic  panels  and  the  number  of  columns  equal  to  the  number  of  retained 
modes. 

Created  By: 

MAPOL 

Notes: 

1.  DTSLP  is  computed  using: 

[DTSLP  ]  =  [BLSTJ A  ]T  [PHXB  ] 

Entity: 

DUAD 

Entity  Type: 

Matrix 

Description: 

Matrix  of  sensitivities  of  the  a-set  accelerations  to  changes  in  the  design  variables. 

Matrix  Form: 

The  number  of  rows  is  equal  to  the  number  of  degrees  of  freedom  in  the  a-set 
while  the  number  of  columns  is  equal  to  the  number  of  active  load  cases  times  the 
number  of  design  variables. 

Created  By: 

MAPOL 

Notes: 

1.  This  matrix  is  formed  by  merging  DURD  and  DULD. 

2.  This  matrix  is  constructed  only  when  there  is  inertia  relief  and  when  the  load 
vectors  have  been  determined  to  be  active  by  module  ABOUND. 
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Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 
Matrix  Form 

Created  By: 
Notes: 


DUAV 

Matrix 

Sensitivity  of  displacements  in  the  a-set. 

The  number  of  columns  is  equal  to  the  number  of  active  subcases  times  the  num¬ 
ber  of  design  variables.  The  number  of  rows  is  equal  to  the  number  of  terms  in 
the  a-set. 

MAPOL,  Module  AEROSENS  or  Module  FBS 

1.  For  static  analysis  without  inertia  relief  DUAV  is  determined  by  FBS;  for  iner¬ 
tia  relief,  DUAV  is  merged  from  DURV  and  DULV.  For  static  aeroelasticity, 
DUAV  is  calculated  in  AEROSENS. 

DUFV 

Matrix 

Sensitivity  of  displacements  in  the  f-set. 

The  number  of  columns  is  equal  to  the  number  of  active  subcases  times  the  num¬ 
ber  of  design  variables.  The  number  of  rows  is  equal  to  the  number  of  terms  in 
the  f-set. 

MAPOL 

1.  For  generalized  dynamic  reduction,  DUFV  is  obtained  from  DUAV  and 
GSUBO.  For  Guyan  Reduction,  DUFV  is  obtained  from  merging  DUAV  and 
temporary  matrix  UO  which  represents  the  sensitivity  of  the  displacements 
in  the  o-set. 

DUG 

Matrix 

Summation  of  the  DRUG  and  DMUG  matrices. 

The  number  of  columns  is  equal  to  NAC,  the  number  of  active  subcases,  times 
NDV,  the  number  of  design  variables.  The  number  of  columns  is  equal  to  the  num¬ 
ber  of  degrees  of  freedom  in  the  g-set. 

MAPOL 

1.  If  there  are  no  SUPPORT  degrees  of  freedom,  DUG  is  equivalenced  into 
DRUG. 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


DULD 

Matrix 

Matrix  of  sensitivities  of  the  1-set  accelerations  to  changes  in  the  design  vari¬ 
ables. 

The  number  of  rows  is  equal  to  the  number  of  degrees  of  freedom  in  the  1-set 
while  the  number  of  columns  is  equal  to  the  number  of  active  load  cases  times  the 
number  of  design  variables, 

MAPOL 

1.  This  matrix  is  formed  by  multiplying  D  by  DURD. 

2.  This  matrix  is  constructed  only  when  there  is  inertia  relief  and  when  the  load 
vectors  have  been  determined  to  be  active  by  module  ABOUND. 

DULV 

Matrix 

Sensitivity  of  displacements  in  the  i-set.  The  computed  sensitivity  of  the  active 
subcases  to  changes  in  the  design  variable. 

The  number  of  columns  is  equal  to  the  number  of  active  subcases  times  the  num¬ 
ber  of  design  variables.  The  number  of  rows  is  equal  to  the  number  of  terms  in 
the  1-set. 

Module  FBS 

1.  This  matrix  is  created  only  when  there  is  statics  with  inertia  relief  and  when 
the  load  vectors  have  been  determined  to  be  active  by  module  ABOUND. 

DURD 

Matrix 

The  sensitivity  of  the  rigid  body  acceleration  matrix  to  changes  in  the  design  vari¬ 
ables. 

Real  and  rectangular.  The  number  of  rows  is  equal  to  the  number  of  degrees  of 
freedom  in  the  r-set  while  the  number  of  columns  is  equal  to  the  number  of  active 
subcases  times  the  number  of  design  variables. 

Module  INERTIA 

1.  This  matrix  is  formed  only  when  there  is  inertia  relief  and  the  applied  load 
has  been  determined  to  be  active  by  module  ABOUND. 

2.  The  matrix  is  formed  by  solving 

[MRR  ]  [DURD  ]  =  [DRHS  ] 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


DVCT 

Relation 

Contains  the  data  required  for  the  assembly  of  the  DESIGN  SENSITIVITY  MA¬ 
TRICES.  Relation  is  sorted  first  by  DVID  and  then  by  KSIL. 


NAME 

TYPE/KEY 

DESCRIPTION 

DVID 

Integer  >  0 

Design  variable  identification  number 

PREF 

Real 

Design  variable  multiplier  for  shape  function 
coefficients 

ALPHA 

Real 

Exponential  power  associated  with  the  design 
variable 

KSIL 

Integer  >  0 

Internal  identification  for  a  grid  connected  to 
the  element 

KCODE 

Integer  >  0 

A  code  word  denoting  the  form  in  which  the 
element  stiffness  matrix  is  stored 

MCODE 

Integer  >  0 

A  code  word  denoting  the  form  in  which  the 
element  mass  matrix  is  stored 

TCODE 

Integer  >  0 

A  code  word  denoting  the  form  in  which  the 
element  thermal  loads  sensitivities  are  stored 

TREFPT 

Integer 

The  position  in  TREF  for  the  associated 
reference  temperature 

NODES 

Integer  >  0 

The  number  of  nodes  connected  to  the  element 

IREC 

Integer  >  0 

The  record  number  of  the  unstructured  entity 
KELM,  MELM,  or  TELM  that  contains  the 
partition  of  the  element  matrix 

ASILS 

Ivector  (32) 

List  of  associated  sils  of  the  element  in  sorted 
order 

Module  EMG 

1.  This  relation  contains  one  tuple  for  each  design  variable  for  each  node  of  each 
structural  element. 
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2.  The  code  words  KCODE,  MCODE  and  TCODE  have  the  following  definition: 


KCODE/MCODE/TCODE 
FOR  SCALAR 
ELEMENTS 

MEANING  (No  meaning  for  TCODE) 

1 

Scalar  point  connected  to  ground 

2 

Grid  point  component  connected  to  a  scalar  point 

3 

Scalar  point  connected  to  grid  component 

4 

Scalar  point  connected  to  a  scalar  point 

5 

Grid  point  component  connected  to  ground 

6 

Grid  point  component  connected  to  a  second  grid  point 
component 

KCODE/MCODE/TCODE 
FOR  OTHER  ELEMENTS 
(CONNECTED  TO  GRID 
POINTS) 

MEANING 

7 

Element  has  extensional  DOF’s  only 

8 

Element  has  rotational  DOF’s  only 

9 

Element  has  both  extension  and  rotation 

10 

Element  matrix  has  only  diagonal  extensional  entries 

11 

Element  matrix  has  only  diagonal  rotational  entries 

12 

Element  matrix  has  diagonal  entries  for  all  grid  point 
DOFs 

3.  A  KCODE,  MCODE  or  TCODE  of  zero  implies  that  the  element  has  no  associ¬ 
ated  stiffness,  mass  or  thermal  load. 

4.  Design  variable  offset  value  is  stored  in  INFO(ll)  from  EMG.  It  is  used  for 
the  pseudo  design  variable  spawned  to  handle  the  non-linear  portion  of  the 
BAR  element  stiffness. 

5.  7,  8,  and  9  are  the  only  values  supported  for  TCODE. 


Entity: 

Entity  Type: 
Description: 
Entity  Structure: 


Created  By: 
Notes: 

Entity: 
Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 


DVSIZE 

Unstructured 

Contains  memory  allocation  information  on  the  DVCT  relation. 


Record  1. 


WORD  1 

Maximum  number  of  DVCT  tuples  associated  with  any 
one  design  variable  other  than  zero 

WORD  2 

Number  of  tuples  connected  to  "design  variable"  zero 

WORD  3  through 
NDV+2 

Number  of  tuples  connected  to  each  design  variable 

Module  EMG 


1.  Entity  contains  one  record  with  NDV  +2  words. 

DWNWSH 

Matrix 

Matrix  containing  downwash  vectors  that  are  computed  for  unit  values  of  angle 
of  attack,  pitch  rate  and  trim  surface  deflection. 

Rectangular  real  matrix  with  three  columns  and  rows  equal  to  the  number  of  pan¬ 
els  in  the  unsteady  aerodynamics  model. 

Module  BLASTFIT 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

FMAX 

Real  >  0 

Highest  frequency  of  interest 

NVEC 

Integer  >  0 

Number  of  generalized  coordinates  desired 

NIT 

Integer  >  0 

Not  Used 

ISEED 

Integer  >  0 

NQDES 

Integer  >  0 

EPZ 

Real 

FACTOR 

Real 

DYNRED 

Relation 


« 


Contains  the  necessary  infoimation  to  perform  general  dynamic  reduction  as  in¬ 
put  from  the  Bulk  Data  file. 


Created  By: 


Module  IFF 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 


Created  By: 
Notes: 


D1JK 

Matrix 

The  real  part  of  the  substantial  derivative  matrix. 

A  rectangular  complex  matrix  with  the  number  of  rows  equal  to  the  number  of 
aerodynamic  degrees  of  freedom  and  the  number  of  columns  equal  to  the  number 
of  aerodynamic  panels. 

Module  UNSTEADY 


1.  The  complete  substantial  derivative  matrix  is  equal  to: 
D1JK  +  (iK)  D2JK 

where  k  is  the  reduced  frequency. 


t 
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Entity: 
Entity  'type: 
Description: 
Matrix  Form 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


D2JK 

Matrix 

The  imaginary  part  of  the  substantial  derivative  matrix. 

A  co  mplex  matrix  with  the  number  of  rows  equal  to  the  number  of  aerodynamic 
degrees  of  freedom  and  the  number  of  columns  equal  to  the  number  of  aerody¬ 
namic  panels. 

Modu.  *  UNSTEADY 

1.  The  complete  substantial  derivative  matrix  is  equal  to: 

D1JK  +  (iK)  D2JK 
where  k  is  the  reduced  frequency. 

EIGC 

Relation 

Contains  the  necessary  information  to  perform  complex  eigenvalue  analysis  as  in¬ 
put  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0,  key 

Set  identification  number 

METHOD 

Tfext  (8) 

Method  of  complex  eigenvalue 
extraction 

NORM 

Tfext  (8) 

Eigenvector  normalization  technique 

GRID1 

Integer  >  0 

Grid  or  a -alar  point  identification 
number 

COMPNTS1 

Integer  >  0 

Component  of  GRID1 

ORTHPARM 

Real  >  0.0 

Mass  orthogonality  test  parameter 

PA 

Real 

The  real  part  of  complex  point  A 

QA 

Real 

The  imaginary  part  of  complex  point  B 

PB 

Real 

The  real  part  of  complex  point  A 

QB 

Real 

The  imaginary  part  of  complex  point  B 

WIDTH 

Real  >  0.0 

Width  of  region  in  complex  plane 

ROOTEST 

Integer  >  0 

Estimated  number  of  roots  in  the  range 

ROOTDES 

Integer  >  0 

Desired  number  of  roots 

Module  IFF 
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EIGR 

Relation 


Entity: 

Entity  Type: 

Description:  Contains  the  necessary  information  to  perform  real  eigenvalue  analysis  as  input 

from  the  Bulk  Data  file. 

Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0,  key 

Set  identification  number 

METHOD 

Text  (8) 

Method  of  eigenvalue  extraction 

MIN FREQ 

Real  >  0.0 

Lower  bound  for  frequency 

MAX FREQ 

Real  >.  0.0 

Upper  bound  for  frequency 

ROOTEST1 

Integer  >  0 

Estimated  number  of  roots  in  the  range 

P.OOTDES'l 

Integer  £  0 

Desired  number  of  roots 

ORTHPARM 

Real  >  0.0 

Mass  orthogonality  test  parameter 

NORM 

Text (81 

Eigenvector  normalization  technique 

GRID1 

Integer  >  0 

Grid  or  scalar  point  identification 
number 

COMPNTS1 

Integer  >  0 

Component  of  GRID1 

Created  By: 

Module  EFP 

Entity: 

ELAS 

Entity  Type: 

Matrix 

Description: 

Intermediate  matrix  in  the  nuclear  blast  response  calculation  containing  the  mo¬ 
dal  participation  factors  for  the  initially  trimmed  aircraft. 

Matrix  Form: 

ELAS  contains  one  column  and  the  numbcT  of  rows  is  equal  to  the  number  of  elas¬ 
tic  modes. 

Created  By: 

Module  MAPOL 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


ELASEST 

Relation 

Contains  the  element  summary  data  for  the  ELAS1  and  ELAS2  elements. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0, 
key 

Element  identification  number 

SIL1,  SIL2 

Integer  £  0 

Internal  grid  or  scalar  point  identification 
number 

COMPNT1 

Integer  £  0 

Component  of  SIL1  to  which  the  element  is 
attached 

COMPNT2 

Integer  5  0 

Component  of  SIL2  to  which  the  element  is 
attached 

K 

Real 

Stiffness  value 

GE 

Real 

DamDiner  coefficient 

STRSCOEF 

Real 

Stress  coefficient 

DESIGN 

Integer  5  0 

Design  flag,  nonzero  if  element  is  designed 

Module  MAKEST 


1.  This  relation  is  built  from  the  CELAS1  and  CELAS2  relations  along  with  as 
sociated  property  and  grid  relations.  It  contains  one  tuple  for  each  scalar 
spring  element  in  the  problem. 

ELEMLIST 

Relation 

Contains  the  list  of  elements  for  which  element  dependent  outputs  are  requested 
as  input  from  the  Bulk  Data  file. 


NAME 

7  YP  E/KEY 

DESCRIPTION 

SID 

Integer  >  0 

Design  vaiiable  identification  number 

ETYPE 

Tbxt  (8) 

Element  type.  One  of  the  following: 

BAR  QDMEM1 

ELAS  QUAD4 

MEX1  ROD 

IHEX2  SHEAR 

IHEX3  TRIA3 

TRMEM 

EID 

Integer  >  0 

Element  identification  number 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


ELIST 

Relation 

Contains  the  element  identification  numbers  of  elements  specified  on  the  ELIST 
Bulk  Data  entry. 


NAME 

TYPE/KEY 

DESCRIPTION 

LINKID 

Integer  >  0 

ELIST  set  identification  number 

ETYPE1 

Text  (8) 

Element  type 

EID1 

Integer  >  0 

Element  identification  number 

Created  By: 
Notes: 


Module  IFF 


1.  Allowable  ETYPE1  entries  are: 

-  CROD,  CONROD 

-  CSHEAR 

-  CQDMEM1 

-  CQUAD4 

-  CTRIA3 

-  CTRMEM 


CMASS1,  CMASS2 

CBAR 

CONM2 

CELAS1,  CELAS2 


502 


Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


EOBAR 

Relation 

Contains  the  element  response  quantities  for  the  BAR  element. 


NAME 

TYPE/KEY 

DESCRIPTION 

OAFLAG 

2  >  Integer  £  1 

Optimize/analyze  flag 
=1  Optimization 
=2  Analysis 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

BCID 

Integer  >  0 

Boundary  condition  identification  number 

DISC 

Integer  >  0 

Discipline  type 

=  1  Statics  =  5  Transient 

=  2  Modes  =  7  Buckling 

=  3  Steady  Aero  =  8  Blast 

SUBCASE 

Integer  >  0 

Subcase  identification  number  if  (DISC  =  1,  3, 

5,  8)  or  Mode  Number  if  (DISC  =  2,  7) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

String 

Element  type  (“BAR”) 

CMPLX 

Integer  >  0 

Complex  output  identifier 
=  1  if  real  response  quantities 
=  2  if  complex  response  quantities 

ESER 

Real 

Real  part  of  element  strain  energy 

E5EI 

Real 

Imaginary  part  of  element  strain  energy 

RSA1 

Real 

Real  part  of  first  bending  stress  at  end  A 

ISA1 

Real 

Imaginary  part  of  first  bending  stress  at  end  A 

RSA2 

Real 

Real  part  of  second  bending  stress  at  end  A 

ISA2 

Real 

Imaginary  part  of  second  bending  stress  at  end 

A 

RSA3 

Real 

Real  part  of  third  bending  stress  at  end  A 

ISA3 

Real 

Imaginary  part  of  third  bending  stress  at  end  A 

RSA4 

Real 

Real  part  of  fourth  bending  stress  at  end  A 

ISA4 

Real 

Imaginary  part  of  fourth  bending  stress  at  end 

A 

RAAX 

Real 

Real  part  of  axial  stress  at  end  A 

IAAX 

Real 

Imaginary  part  of  axial  stress  at  end  A 

MAXA 

Real 

Maximum  stress  at  end  A 

MINA 

Real 

Minimum  stress  at  end  A 
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NAME 


TYPE/KEY 


DESCRIPTION 


TSAFE 

Real 

Safety  margin  in  tension 

RSB1 

Real 

Real  part  of  first  bending  stress  at  end  B 

ISB1 

Real 

Imaginary  part  of  first  bending  stress  at  end  B 

RSB2 

Real 

Real  part  of  second  bending  stress  at  end  B 

ISB2 

Real 

Imaginary  part  of  second  bending  stress  at  end 

B 

RSB3 

Real 

Real  part  of  third  bending  stress  at  end  B 

ISB3 

Real 

Imaginary  part  of  third  bending  stress  at  end  B 

RSB4 

Real 

Real  part  of  fourth  bending  stress  at  end  B 

ISB4 

Real 

Imaginary  part  of  fourth  bending  stress  at  end 

B 

RBAX 

Real 

Real  part  of  axial  stress  at  end  B 

I  BAX 

Real 

Imaginary  part  of  axial  stress  at  end  B 

MAXB 

Real 

Maximum  stress  at  end  B 

MINB 

Real 

Minimum  stress  at  end  B 

CSAFE 

Real 

Safety  margin  in  compression 

RSNA1 

Real 

Real  part  of  first  bending  strain  at  end  A 

ISNA1 

Real 

Imaginary  part  of  first  bending  strain  at  end  A 

RSNA2 

Real 

Real  part  of  second  bending  strain  at  end  A 

ISNA2 

Real 

Imaginary  part  of  second  bending  strain  at  end 

A 

RSNA3 

Real 

Real  part  of  third  bending  strain  at  end  A 

ISNA3 

Real 

Imaginary  part  of  third  bending  strain  at  end  A 

RSNA4 

Real 

Real  part  of  fourth  bending  strain  at  end  A 

ISNA4 

Real 

Imaginary  part  of  fourth  bending  strain  at  end 

A 

RAAXN 

Real 

Real  part  of  axial  strain  at  end  A 

IAAXN 

Real 

Imaginary  part  of  axial  strain  at  end  A 

MAXAN 

Real 

Maximum  strain  at  end  A 

MINAN 

Real 

Minimum  strain  at  end  A 

RSNB1 

Real 

Real  part  of  first  bending  strain  at  end  B 

ISNB1 

Real 

Imaginary  part  of  first  bending  strain  at  end  B 

RSNB2 

Real 

Real  part  of  second  bending  strain  at  end  B 

t 
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Created  By: 
Notes: 


NAME 

TYPE/KEY 

DESCRIPTION 

ISNB2 

Real 

Imaginary  part  of  second  bending  strain  at  end 

B 

RSNB3 

Real 

Real  part  of  third  bending  strain  at  end  B 

ISNB3 

Real 

Imaginary  part  of  third  bending  strain  at  end  B 

RSNB4 

Real 

Real  part  of  fourth  bending  strain  at  end  B 

ISNB4 

Real 

Imaginary  part  of  fourth  bending  strain  at  end 

B 

RBAXN 

Real 

Real  part  of  axial  strain  at  end  B 

IBAXN 

Real 

Imaginary  part  of  axial  strain  at  end  B 

MAX  BN 

Real 

Maximum  strain  at  end  B 

MIN  BN 

Real 

Minumum  strain  at  end  B 

RBMA1 

Real 

Real  part  of  bending  moment  A1 

IBMA1 

Real 

Imaginary  part  of  bending  moment  A1 

RBMA2 

Real 

Real  part  of  bending  moment  A2 

IBMA2 

Real 

Imaginary  part  of  bending  moment  A2 

RBMB1 

Real 

Real  part  of  bending  moment  B1 

IBMB1 

Real 

Imaginary  part  of  bending  moment  B1 

RBMB2 

Real 

Real  part  of  bending  moment  B2 

IBMB2 

Real 

Imaginary  part  of  bending  moment  B2 

RSHEAR1 

Real 

Real  part  of  shear  1 

ISHEAR1 

Real 

Imaginary  part  of  shear  1 

RSHEAR2 

Real 

Real  part  of  shear  2 

ISHEAR2 

Real 

Imaginary  part  of  shear  2 

RFORAX 

Real 

Real  part  of  axial  force 

IFCRAX 

Real 

Imaginary  part  of  axial  force 

RTORQUE 

Real 

Real  part  of  torque 

ITORQUE 

Real 

Imaginary  part  of  torque 

Module  EDR 

1.  This  relation  is  used  by  module  OFPEDR  for  output  printing  and  punching. 
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Entity: 
Entity  Type: 
Description: 

Record: 


Created  By: 
Notes: 


EODISC 

Unstructured 

Contains  the  element  discipline  types  and  their  subcases  for  which  element  re¬ 
sponse  quantities  are  to  be  computed  for  each  element  in  the  structural  model  for 
each  boundary  condition. 

i.  Record  i  contains  the  following  for  each  EID/BCED  combination  to  the  EO- 
SUMMARY  relation. 


WORD 

CONTENTS 

1 

NDISC,  the  number  of  disciplines  in  the  EODISC  record 

2 

DISC,  discipline  ID  for  the  current  discipline 

3 

NSUB,  the  number  of  subcases  for  which  output  is  desired 
from  discipline  DISC 

4  to  3+NSUB 

SUBj,  the  subcase  numbers  in  sorted  order 

Module  PFBULK 

1.  Words  2  through  4+NSUB  are  repeated  for  each  of  the  NDISC  disciplines  to 
generate  a  record  in  the  form. 

NDISC  (DISCi,  NSUBi,  (SUBj),  f- =  1,NSUB),  i=  1,  NDISC) 

2.  Each  record  of  EODISC  is  referenced  by  the  RECORD  attribute  of  the  EO- 
SUMMARY  relation. 

3.  The  EOSUMMARY/EODISC  combination  is  used  by  EDR  and  OFPEDR  to 
control  element  response  quantity  computations. 

4.  Each  record  is  ordered  in  discipline,  in  subrase  order. 

5.  The  records  are  ordered  by  boundary  condition  ID,  element  type  (alphabeti¬ 
cal)  and  element  ID. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


EOELAS 

Relation 

Contains  the  element  response  quantities  for  the  ELAS  element. 


NAME 

TYPE/KEY 

DESCRIPTION 

OAFLAG 

2  2  Integer  >  1 

Optimize/analyze  flag 
=1  Optimization 
=2  Analysis 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

BCID 

Integer  >  0 

Boundary  condition  identification  number 

DISC 

Integer  >  0 

Discipline  type 

=  1  Statics  =  5  Transient 

=  2  Modes  =  7  Buckling 

=  3  Steady  Aero  =  8  Blast 

SUBCASE 

Integer  >  0 

Subcase  identification  number  if  (DISC  =  1, 3, 

5,  8)  or  Mode  Number  if  (DISC  =  2,  7) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

String 

Element  type  (“ELAS”) 

CMPLX 

Integer  >  0 

Complex  output  identifier 
=  1  if  real  response  quantities 
=  2  if  complex  response  quantities 

ESER 

Real 

Real  part  of  element  strain  energy 

ESEI 

Real 

Imaginary  part  of  element  strain  energy 

STRSR 

Real 

Real  part  of  stress 

STRSI 

Real 

Imaginary  part  of  stress 

FORR 

Real 

Real  part  of  force 

FORI 

Real 

Imaginary  part  of  force 

Module  EDR 


1.  This  relation  is  used  by  module  OFPEDR  for  output  printing  and  punching. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

OAFLAG 

2  >  Integer  >  1 

Optimize/analyze  flag 
=1  Optimization 
=2  Analysis 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

BCID 

Integer  >  0 

Boundary  condition  identification  number 

DISC 

Integer  >  0 

Discipline  type 

=  1  Statics  =  5  Transien 

=  2  Modes  =  7  Buckling 

=  3  Steady  Aero  =  8  Blast 

SUBCASE 

Integer  >  0 

Subcase  identification  number  if  (DISC  = 

1,  3,  5,  8)  or  Mode  Number  if  (DISC  =  2,  7) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

String 

Element  type  HHEXl") 

CMP  LX 

Integer  >  0 

Complex  output  identifier 
=  1  if  real  response  quantities 
=  2  if  complex  response  quantities 

GID 

Integer  >  0 

Stress  point  identification  number 

ESER 

Real 

Real  part  of  element  strain  energy 

ESEI 

Real 

Imaginary  part  of  element  strain  energy 

RSTRSX 

Real 

Real  part  of  normal  stress  in  x-direction 

ISTRSX 

Real 

Imaginary  part  of  normal  stress  in  x- 
direction 

RSSXY 

Real 

Real  part  of  shear  stress  in  xy-plane 

ISSXY 

Real 

Imaginary  part  of  shear  stress  in  xy-plane 

PSTRESS1 

Real 

First  principal  stress 

XCOS1 

Real 

First  principal  x  cosine 

XCOS2 

Real 

Second  principal  x  cosine 

XCOS3 

Real 

Third  principal  x  cosine 

MEANSTRS 

Real 

Mean  stress 

OCTSTRS 

Real 

Octahedral  shear  stress 

RSTRSY 

Real 

Real  part  of  normal  stress  in  y-direction 

EOHEX1 

Relation 

Contains  the  element  response  quantities  for  the  IHEX1  element. 
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NAME 


TYPE/KEY 


DESCRIPTION 


ISTRSY 

Real 

Imaginary  part  of  normal  stress  in  y- 
direction 

RSSYZ 

Real 

Real  part  of  normal  stress  in  yz-direetion 

ISSYZ 

Real 

Imaginary  part  of  normal  stress  in  yz~ 
direction 

PSTRESS2 

Real 

Second  principal  stress 

YCOS1 

Real 

First  principal  y  cosine 

YCOS2 

Real 

Second  principal  y  cosine 

YCOS3 

Real 

Third  principal  y  cosine 

RSTRSZ 

Real 

Real  part  of  normal  stress  in  z-direction 

ISTRSZ 

Real 

Imaginary  part  of  normal  stress  in  z- 
direction 

RSSZX 

Real 

Real  part  of  shear  stress  in  zx-plane 

ISSZX 

Real 

Imaginary  part  of  shear  stress  in  zx-plane 

PSTRESS3 

Real 

Third  principal  stress 

ZCOS1 

Real 

First  principal  z  cosine 

ZCOS2 

Real 

Second  principal  z  cosine 

ZCOS3 

Real 

Third  principal  z  cosine 

RSTRNX 

Real 

Real  part  of  normal  strain  in  x-direction 

ISTRNX 

Real 

Imaginary  part  of  normal  strain  in  x- 
direction 

RSNXY 

Real 

Real  part  of  shear  strain  in  xy-plane 

ISNXY 

Real 

Imaginary  part  of  shear  strain  in  xy-plane 

PSTRAIN1 

Real 

First  principal  strain 

XCOS1N 

Real 

First  principal  x  cosine 

XCOS2N 

Real 

Second  principal  x  cosine 

XCOS3N 

Real 

Third  principal  x  cosine 

MEANSTRN 

Real 

Mean  strain 

OCTSTRN 

Real 

Octahedral  shear  strain 

RSTRNY 

Real 

Real  part  of  normal  strain  in  y-direction 

ISTRNY 

Real 

Imaginary  part  of  normal  strain  in  y- 
direction 

RSNYZ 

Real 

Real  part  of  shear  strain  in  yz-plane 

ISNYZ 

Real 

Imaginary  part  of  shear  strain  in  yz-plane 
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NAME 

TYPE/KEY 

DESCRIPTION 

PSTRAIN2 

Real 

Second  principal  strain 

YCOS1N 

Real 

First  principal  y  cosine 

YCOS2N 

Real 

Second  principal  y  cosine 

YCOS3N 

Real 

Third  principal  y  cosine 

RSTRNZ 

Real 

Real  part  of  normal  strain  in  z-direction 

ISTRNZ 

Real 

Imaginary  part  of  normal  strain  in  z- 
direction 

RSNZX 

Real 

Real  part  of  shear  strain  in  zx-plane 

ISNZX 

Real 

Imaginary  part  of  shear  strain  in  zx-plane 

PSTRA.IN3 

Real 

Third  principal  strain 

ZCOS1N 

Real 

First  principal  z  cosine 

ZCOS2N 

Real 

Second  principal  z  cosine 

ZCOS3N 

Real 

Third  principal  z  cosine 

Created  By:  Module  EDR 

Notes: 

1.  This  relation  is  used  by  module  OFPEDR  for  output  printing  and  punching. 

2.  One  tuple  exists  for  each  of  the  nine  stress  points  in  the  element. 

3.  The  first  eight  stress  points  (attribute  GID)  are  coincident  with  the  element 
grid  points  and  are  numbered  1  through  8  in  the  order  that  the  grid  points 
are  specified  on  the  CIHEX1  entity.  The  ninth  stress  point  (GID=9)  is  located 
at  the  center  of  the  element. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIP  HON 

OAFLAG 

2  >  Integer  >  1 

Optimize/analyze  flag 
=1  Optimization 
=2  Analysis 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

BCID 

Integer  >  0 

Boundary  condition  identification  number 

DISC 

Integer  >  0 

Discipline  type 

=  1  Statics  =  5  Transien . 

=  2  Modes  =  7  Buckling 

=  3  Steady  Aero  =  8  Blast 

SUBCASE 

Integer  >  0 

Subcase  identification  number  if  (DISC  = 

1,  3,  5,  8)  or  Mode  Number  if  (DISC  =  2,  7) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

String 

Element  type  (“EHEX2”) 

CMP  LX 

Integer  >  0 

Complex  output  identifier 
=  1  if  real  response  quantities 
=  2  if  complex  response  quantities 

GID 

Integer  >  0 

Stress  point  identification  number 

ESER 

Real 

Real  part  of  element  strain  energy 

ESEI 

Real 

Imaginary  part  of  element  strain  energy 

RSTRSX 

Real 

Real  part  of  normal  stress  in  x-direction 

ISTRSX 

Real 

Imaginary  part  of  normal  stress  in  x- 
direction 

RSSXY 

Real 

Real  part  of  shear  stress  in  xy-plane 

ISSXY 

Real 

Imaginary  part  of  shear  stress  in  xy-plane 

PSTRESS1 

Real 

First  principal  stress 

XCOS1 

Real 

First  principal  x  cosine 

XCOS2 

Real 

Second  principal  x  cosine 

XCOS3 

Real 

Third  principal  x  cosine 

MEANSTRS 

Real 

Mean  stress 

OCTSTRS 

Real 

Octahedral  shear  stress  j 

RSTRSY 

Real 

Real  part  of  normal  stress  in  y-direction 

EOHEX2 

Relation 

Contains  the  element  response  quantities  for  the  IHEX2  element. 
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NAME 

TYFE/KEY 

DESCRIPTION 

ISTRSY 

Real 

Imaginary  part  of  normal  stress  in  y- 
direction 

RSSYZ 

Real 

Real  part  of  normal  stress  in  yz-plane 

ISSYZ 

Real 

Imaginary  part  of  normal  stress  in  yz-plane 

PSTRESS2 

Real 

Second  principal  stress 

YC0S1 

Real 

First  principal  y  cosine 

YCOS2 

Real 

Second  principal  y  cosine 

YCOS3 

Real 

Third  principal  y  cosine 

RSTRSZ 

Real 

Real  part  of  normal  stress  in  z-direction 

ISTRSZ 

Real 

Imaginary  part  of  normal  stress  in  z- 
direction 

RSSZX 

Real 

Real  part  of  shear  stress  in  xy-plane 

ISSZX 

Real 

Imaginary  part  of  shear  stress  in  xy-plane 

PSTRESS3 

Real 

Third  principal  stress 

ZCOS1 

Real 

First  principal  z  cosine 

ZCOS2 

Real 

Second  principal  z  cosine 

ZCOS3 

Real 

Third  principal  z  cosine 

RSTRNX 

Real 

Real  part  of  normal  strain  in  x-direction 

ISTRNX 

Real 

Imaginary  part  of  normal  strain  in  x- 
direction 

RSNXY 

Real 

Real  part  of  shear  strain  in  xy-plane 

ISNXY 

Real 

Imaginary  part  of  shear  strain  in  xy-plane 

PSTRAIN1 

Real 

First  principal  strain 

XCOS1N 

Real 

First  principal  x  cosine 

XCOS2N 

Real 

Second  principal  x  cosine 

XCOS3N 

Real 

Third  principal  x  cosine 

MEAN3TRN 

Real 

Mean  strain 

OCTSTRN 

Real 

Octahedral  shear  strain 

RSTRNY 

Real 

Real  part  of  normal  strain  in  y-direction 

ISTRNY 

Real 

Imaginary  part  of  normal  strain  in  y- 
direction 

RSNYZ 

Real 

Real  part  of  shear  strain  in  yz-plane 

ISNYZ 

Real 

Imaginary  part  of  shear  strain  in  yz-plane 

PSTRAIN2 

Real 

Second  principal  strain 
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Created  By: 
Notes: 


NAME 

TYPE/KEY 

DESCRIPTION 

YCOS1N 

Real 

First  principal  y  cosine 

YCOS2N 

Real 

Second  principal  y  cosine 

YCOS3N 

Real 

Third  principal  y  cosine 

RSTRNZ 

Real 

Real  part  of  normal  strain  in  z-direction 

ISTRNZ 

Real 

Imaginary  part  of  normal  strain  in  z- 
direction 

RSTZX 

Real 

Real  part  of  shear  strain  in  z-direction 

ISNZX 

Real 

Imaginary  part  of  shear  strain  in  z- 
direction 

PSTRAIN3 

Real 

Third  principal  strain 

ZCOS1N 

Real 

First  principal  z  cosine 

ZCOS2N 

Real 

Second  principal  z  cosine 

ZCOS3N 

Real 

Third  principal  z  cosine 

Module  EDR 

1.  This  relation  is  used  by  module  OFPEDR  for  output  printing  and  punching. 

2.  One  tuple  exists  for  each  of  the  nine  stress  points  in  the  element. 

3.  The  first  20  stress  points  are  in  the  same  order  as  the  grid  points  are  speci¬ 
fied  on  the  CIHEX2  entity  and  are  numbered  1  through  20.  The  corner  stress 
points  coincident  with  the  corner  grid  points  while  the  mid-edge  stress  points 
are  exactly  at  the  mid-edge  point.  The  21st  stress  point  is  located  at  the  ele¬ 
ment  center. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

OAFLAG 

2  k  Integer  £  1 

Optimize/analyze  flag 
=1  Optimization 
=2  Analysis 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

BCID 

Integer  >  0 

Boundary  condition  identification  number 

DISC 

Integer  >  0 

Discipline  type 

=  1  Statics  =  5  Transien 

=  2  Modes  =  7  Buckling 

=  3  Steady  Aero  =  8  Blast 

SUBCASE 

Integer  >  0 

Subcase  identification  number  if  (DISC  = 

1,  3,  5,  8)  or  Mode  Number  if  (DISC  =  2,  7) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

String 

Element  type  (“IHEX3”) 

CMP  LX 

Integer  >  0 

Complex  output  identifier 
=  1  if  real  response  quantities 
=  2  if  complex  response  quantities 

GID 

Integer  >  0 

Stress  point  identification  number 

ESER 

Real 

Real  part  of  element  strain  energy 

ESEI 

Real 

Imaginary  part  of  element  strain  energy 

RSTRSX 

Real 

Real  part  of  normal  stress  in  x-direction 

ISTRSX 

Real 

Imaginary  part  of  normal  stress  in  x- 
direction 

RSSXY 

Real 

Real  part  of  shear  stress  in  xy-plane 

ISSXY 

Real 

Imaginary  part  of  shear  stress  in  xy-plane 

PSTRESS1 

Real 

First  principal  stress 

XCOS1 

Real 

First  principal  x  cosine 

XCOS2 

Real 

Second  principal  x  cosine 

XCOS3 

Real 

Third  principal  x  cosine 

MEANSTRS 

Real 

Mean  stress 

OCTSTRS 

Real 

Octahedral  shear  stress 

RSTRSY 

Real 

Real  part  of  normal  stress  in  y-direction 

EOHEX3 

Relation 

Contains  the  element  response  quantities  for  the  IHEX3  element. 
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NAME 

TYPE/KEY 

DESCRIPTION 

ISTRSY 

Real 

Imaginary  part  of  normal  stress  in  y- 
direction 

RSSYZ 

Real 

Real  part  of  normal  stress  in  yz-plane 

ISSYZ 

Real 

Imaginary  part  of  normal  stress  in  yz-plane 

PSTRESS2 

Real 

Second  principal  stress 

YC0S1 

Real 

First  principal  y  cosine 

YCOS2 

Real 

Second  principal  y  cosine 

YCOS3 

Real 

Third  principal  y  cosine 

RSTRSZ 

Real 

Real  part  of  normal  stress  in  z-direction 

ISTRSZ 

Real 

Imaginary  part  of  normal  stress  in  z- 
direction 

RSSZX 

Real 

Real  part  of  shear  stress  in  xy-plane 

ISSZX 

Real 

Imaginary  part  of  shear  stress  in  xy-plane 

PSTRESS3 

Real 

Third  principal  stress 

ZCOS1 

Real 

First  principal  z  cosine 

ZCOS2 

Real 

Second  principal  z  cosine 

ZCOS3 

Real 

Third  principal  z  cosine 

RSTRNX 

Real 

Real  part  of  normal  strain  in  x-direction 

ISTRNX 

Real 

Imaginary  part  of  normal  strain  in  x- 
direction 

RSNXY 

Real 

Real  part  of  shear  strain  in  xy-plane 

ISNXY 

Real 

Imaginary  part  of  shear  strain  in  xy-plane 

Real 

First  principal  strain 

XCOS1N 

Real 

First  principal  x  cosine 

XCOS2N 

Real 

Second  principal  x  cosine 

XCOS3N 

Real 

Third  principal  x  cosine 

MEANSTRN 

Real 

Mean  strain 

OCTSTRN 

Real 

Octahedral  shear  strain 

RSTRNY 

Real 

Real  part  of  normal  strain  in  y-direction 

ISTRNY 

Real 

Imaginary  part  of  normal  strain  in  y- 
direction 

RSNYZ 

Real 

Real  part  of  shear  strain  in  yz-plane 

ISNYZ 

Real 

Imaginary  part  of  shear  strain  in  yz-plane 

PSTRAIN2 

Real 

Second  principal  strain 
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Created  By: 
Notes: 


NAME 

TYPE/KEY 

DESCRIPTION 

YCOS1N 

Real 

First  principal  y  cosine 

YCOS2N 

Real 

Second  principal  y  cosine 

YCOS3N 

Real 

Third  principal  y  cosine 

RSTRNZ 

Real 

Real  part  of  normal  strain  in  z-direction 

ISTRNZ 

Real 

Imaginary  part  of  normal  strain  in  z - 
direction 

RSTZX 

Real 

Real  part  of  shear  strain  in  z-direction 

ISNZX 

Real 

Imaginary  part  of  shear  strain  in  z- 
direction 

PSTRAIN3 

Real 

Third  principal  strain 

Z COS IN 

Real 

First  principal  z  cosine 

ZCOS2N 

Real 

Second  principal  z  cosine 

ZCOS3N 

Real 

Third  principal  z  cosine 

Module  EDR 

1.  This  relation  is  used  by  module  OFPEDR  for  output  printing  and  punching. 

2.  One  tuple  exists  for  each  of  the  nine  stress  points  in  the  element. 

3.  The  first  20  stress  points  are  in  the  same  order  as  the  grid  points  are  speci¬ 
fied  on  the  CIHEX3  entity  and  are  numbered  1  through  20.  The  corner  stress 
points  coincident  with  the  corner  grid  points  while  the  mid-edge  stress  points 
are  exactly  at  the  mid-edge  point.  The  21st  stress  point  is  located  at  the  ele¬ 
ment  center. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes 


NAME 

TYPE/KEY 

DESCRIPTION 

OAFLAG 

2  >  Integer  >  1 

Optimize/analyze  flag 
=1  Optimization 
=2  Analysis 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

BCID 

Integer  >  0 

Boundary  condition  identification  number 

DISC 

Integer  >  0 

Discipline  type 

=  1  Statics  =  5  Transien 

=  2  Modes  =  7  Buckling 

=  3  Steady  Aero  =  8  Blast 

SUBCASE 

Integer  >  0 

Subcase  identification  number  if  (DISC  = 

1,  3,  5,  8)  or  Mode  Number  if  (DISC  =  2,  7) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

String 

Element  type  (“QDMEM1”) 

CMP  LX 

Integer  >  0 

Complex  output  identifier 
=  1  if  real  response  quantities 
=  2  if  complex  response  quantities 

LAYRNUM 

Integer  >  0 

Layer  number 

ESER 

Real 

Real  part  of  element  strain  energy 

ESEI 

Real 

Imaginary  part  of  element  strain  energy 

RSTRSX 

Real 

Real  part  of  normal  stress  in  x-direction 

ISTRSX 

Real 

Imaginary  part  of  normal  stress  in  x- 
direction 

RSTRSY 

Real 

Real  part  of  normal  stress  in  y-direction 

ISTRSY 

Real 

Imaginary  part  of  normal  stress  in  y- 
direction 

RSTRSS 

Real 

Real  part  of  shear  stress 

ISTRSS 

Real 

Imaginary  part  of  shear  stress 

THSTRS 

Real 

Principal  angle  for  stress 

STRS1 

Real 

Mqjor  principal  stress 

STRS2 

Real 

Minor  principal  stress 

MSSTRS 

Real 

Maximum  shear  stress 

RSTRNX 

Real 

Real  part  of  normal  strain  in  x-direction 

EOQDMM1 

Relation 

Contains  the  element  response  quantities  for  the 
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Created  By: 
Notes: 


NAME 

TYPE/KEY 

DESCRIPTION 

ISTRNX 

Real 

Imaginary  part  of  normal  strain  in  x- 
direction 

RSTRNY 

Real 

Real  part  of  normal  strain  in  y-direction 

ISTRNY 

Real 

Imaginary  part  of  normal  strain  in  y- 
direction 

RSTRNS 

Real 

Real  part  of  shear  strain 

ISTRNS 

Real 

Imaginary  part  of  shear  strain 

THSTRN 

Real 

Principal  angle  for  strain 

STRN1 

Real 

Mayor  principal  strain 

STRN2 

Real 

Minor  principal  atrain 

MSSTRN 

Real 

Maximum  shear  strain 

RFX 

Real 

Real  part  of  force  in  x-direction 

IFX 

Real 

Imaginary  part  of  force  in  x-direction 

RFY 

Real 

Real  part  of  force  in  y-direction 

IFY 

Real 

Imaginary  part  of  force  in  y-direction 

RFXY 

Real 

Real  part  of  shear  force  in  xy-plane 

IFXY 

Real 

Imaginary  part  of  shear  force  in  xy-plane 

Module  EDR 

1.  This  relation  is  used  by  module  OFPEDR  for  output  printing  and  punching. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

OAFLAG 

2  >  Integer  >  1 

Optimize/analyze  flag 
=1  Optimization 
=2  Analysis 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

BCID 

Integer  >  0 

Boundary  condition  identification  number 

DISC 

Integer  >  0 

Discipline  type 

=  1  Statics  =  5  TVansien . 

=  2  Modes  =  7  Buckling 

=  3  Steady  Aero  -  8  Blast 

SUBCASE 

Integer  >  0 

Subcase  identification  number  if  (DISC  = 

1,  3,  5,  8)  or  Mode  Number  if  (DISC  =  2,  7) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

String 

Element  type  (“QUAD4”) 

CMPLX 

Integer  >  0 

Complex  output  identifier 
=  1  if  real  response  quantities 
=  2  if  complex  response  quantities 

LAYRNUM 

Integer  >  0 

Layer  number 

ESER 

Real 

Real  part  of  element  strain  energy 

ESEI 

Real 

Imaginary  part  of  element  strain  energy 

Z1 

Real 

Fiber  distance  1 

RSTRSXl 

Real 

Real  part  of  normal  stress  in  x-direction  at 

Z1 

ISTRSXl 

Real 

Imaginary  part  of  normal  stress  in  x- 
direction  at  Z1 

RSTRSYl 

Real 

Real  part  of  stress  in  y-direction  at  Z1 

ISTRSYl 

Real 

Imaginary  part  of  stress  in  y-direction  at  Z1 

RSSXY1 

Real 

Real  part  of  shear  stress  at  Z1 

ISSXY1 

Real 

Imaginary  part  of  shear  stress  at  Z1 

ANGLES 1 

Real 

Principal  angle  for  stress  at  Z1 

STRS11 

Real 

Major  principal  stress  at  Z1 

STRS12 

Real 

Minor  principal  stress  at  Z1 

MAXSS1 

Real 

Maximum  shear  stress  at  Z1 

EOQUAD4 

Relation 

Contains  the  element  response  quantities  for  the  QUAD4  element. 
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NAME 

TYPE/KEY 

DESCRIPTION 

22 

Real 

Fiber  distance  2 

RSTRSX2 

Real 

Real  part  of  stress  in  x-direction  at  Z2 

ISTRSX2 

Real 

Imaginary  part  of  stress  in  x-direction  at  Z2 

RSTRSY2 

Real 

Real  part  of  stress  in  y-direction  at  Z2 

ISTRSY2 

Real 

Imaginary  part  of  stress  in  y-direction  at  Z2 

RSSXY2 

Real 

Real  part  of  shear  stress  at  Z2 

ISSXY2 

Real 

Imaginary  part  of  shear  stress  at  Z2 

ANGLES2 

Real 

Principal  angle  for  stress  at  Z2 

STRS21 

Real 

Major  principal  stress  at  Z2 

STRS22 

Real 

Minor  principal  stress  at  Z2 

MAXSS2 

Real 

Maximum  shear  stress  at  Z2 

RSTRNX1 

Real 

Real  part  of  strain  in  x-direction  at  Z1 

ISTRNX1 

Real 

Imaginary  part  of  strain  in  x-direction  at  Z1 

RSTRNY1 

Real 

Real  part  of  strain  in  y-direction  at  Z1 

ISTRNY1 

Real 

Imaginary  part  of  strain  in  y-direction  at  Z1 

RSNXY1 

Real 

Real  part  of  shear  strain  at  Z1 

ISNXY1 

Real 

Imaginary  part  of  shear  strain  at  Z1 

ANGLEN1 

Real 

Principal  axis  angle  at  Z1 

STRN11 

Real 

Mayor  principal  strain  at  Z1 

STRN12 

Real 

Minor  principal  strain  at  ZI 

MAXNS1 

Real 

Maximum  shear  strain  at  Zl 

RSTRNX2 

Real 

Real  part  of  strain  in  x-direction  at  Z2 

ISTRNX2 

Real 

Imaginary  part  of  strain  in  x-direction  at  Z2 

RSTRNY2 

Real 

Real  part  of  strain  in  y-direction  at  Z2 

ISTRNY2 

Real 

Imaginary  part  of  strain  in  y-direction  at  Z2 

RSNXY2 

Real 

Real  part  of  shear  strain  at  Z2 

ISNXY2 

Real 

Imaginary  part  of  shear  strain  at  Z2 

ANGELN2 

Real 

Principal  axis  angle  at  Z2 

STRN21 

Real 

Major  principal  strain  at  Z2 

STRN22 

Real 

Minor  principal  strain  at  Z2 

MAXSN2 

Real 

Maximum  shear  strain  at  Z2 

RMEMX 

Real 

Real  part  of  membrane  force  in  x-direction 
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Created  By: 
Notes: 


NAME 

TYPE/KEY 

DESCRIPTION 

IMEMX 

Real 

Imaginary  part  of  membrane  force  in  x- 
direction 

RMEMY 

Real 

Real  part  of  membrane  force  in  y-direction 

IMEMY 

Real 

Imaginary  part  of  membrane  i'rrce  in  y 
direction 

RMEMXY 

Real 

Real  part  of  membrane  force  in  xy-plane 

IMEMXY 

Real 

Imaginary  part  of  membrane  force  in  xy- 
plane 

RBENDX 

Real 

Real  part  of  bending  moment  in  x-direction 

IBENDX 

Real 

Imaginary  part  of  bending  moment  in  x- 
direction 

RBENDY 

Real 

Real  part  of  bending  moment  in  y-direction 

IBENDY 

Real 

Imaginary  part  of  bending  moment  in  y- 
direction 

RBENDXY 

Real 

Real  part  of  bending  moment  in  xy-plane 

IBENDXY 

Real 

Imaginary  part  of  bending  moment  in  xy- 
plane 

RSHEARX 

Real 

Real  part  of  shear  force  in  x-direction 

ISHEARX 

Real 

Imaginary  part  of  shear  force  in  x-direction 

RSHEARY 

Real 

Real  part  of  shear  force  in  y-direction 

ISHEARY 

Real 

Imaginary  part  of  shear  force  in  y-direction 

Module  EDR 


1.  This  relation  is  used  by  module  OFPEDR  for  printing  and  punching. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


EOROD 

Relation 

Contains  the  element  response  quantities  for  the  ROD  element. 


NAME 

TYPe/KEY 

DESCRIPTION 

OAE  LAG 

2  >  Integer  >  1 

Optimize/analyze  flag 
=1  Optimization 
-2  Analysis 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

BCID 

Integer  >  0 

Boundary  condition  identification  number 

DISC 

Integer  >  0 

Discipline  type 

=  1  Statics  =  5  Transien 

=  2  Modes  =  7  Buckling 

=  3  Steady  Aero  =  8  Blast 

SUBCASE 

Integer  >  0 

Subcase  identification  number  if  (DISC  = 

1,  3,  5,  8)  or  Mode  Number  if  (DISC  =  2,  7) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

String 

Element  type  (“ROD”) 

CMPLX 

Integer  >  0 

Complex  output  identifier 
=  1  if  real  response  quantities 
=  2  if  complex  response  quantities 

ESER 

Real 

Real  part  of  element  strain  energy 

ESEI 

Real 

Imaginary  part  of  element  strain  energy 

RAXSTRS 

Real 

Real  part  of  axial  stress 

IAXSTRS 

Real 

Imaginary  part  of  axial  stress 

RTORSTRS 

Real 

Real  part  of  torsional  stress 

ITORSTRS 

Real 

Imaginary  part  of  torsional  stress 

AMARSTRS 

Real 

Axial  stress  margin  of  safety 

TMARSTRS 

Real 

Tbrsional  stress  margin  of  safety 

RAXSTRN 

Real 

Real  part  of  axial  strain 

IAXSTRN 

Real 

Imaginary  part  of  axial  strain 

RTORSTRN 

Real 

Real  part  of  torsional  strain 

ITORSTRN 

Real 

Imaginary  part  of  torsional  strain 

RAX FOR 

Real 

Real  part  of  axial  force 

IAXFOR 

Real 

Imaginary  part  of  axial  force 

RTORQUE 

Real 

Real  part  of  torsional  force 

ITORQUE 

Real 

Imaginary  part  of  torsional  force 

Module  EDR 


1.  This  relation  is  used  by  module  OFPEDR  for  printing  and  punching. 
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EOSHEAR 

Relation 

Contains  the  element  response  quantities  for  the  SHEAR  element. 


Entity: 

Entity  'iype: 
Description: 
Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

OAFLAG 

2  >  Integer  >  1 

Optimize/analyze  flag 
=1  Optimization 
=2  Analysis 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

BCID 

Integer  >  0 

Boundary  condition  identification  number 

DISC 

Integer  >  0 

Discipline  type 

=  1  Statics  =  5  Transien 

=  2  Modes  =  7  Buckling 

=  3  Steady  Aero  =  8  Blast 

SUBCASE 

Integer  >  0 

Subcase  identification  number  if  (DISC  = 

1,  3,  5,  8)  or  Mode  Number  if  (DISC  =  2,  7) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

String 

Element  type  (“SHEAR”) 

CMP  LX 

Integer  >  0 

Complex  output  identifier 
=  1  if  real  response  quantities 
=  2  if  complex  response  quantities 

ESER 

Real 

Real  part  of  element  strain  energy 

ESEI 

Real 

Imaginary  part  of  element  strain  energy 

RMAXSTRS 

Real 

Real  part  of  maximum  shear  stress 

IMAXSTRS 

Real 

Imaginary  part  of  maximum  shear  stress 

RAVESTRS 

Real 

Real  part  of  average  shear  stress 

IAVESTRS 

Real 

Imaginary  part  of  average  shear  stress 

SMARSTRS 

Real 

Stress  safety  margin 

RMAXSTRN 

Real 

Real  part  of  maximum  shear  strain 

IMAXSTRN 

Real 

Imaginary  part  of  maximum  shear  strain 

RAVESTRN 

Real 

Real  part  of  average  shear  strain 

IAVESTRN 

Real 

Imaginary  part  of  average  shear  strain 

RF14 

Real 

Real  part  of  normal  force  on  1  from  4 

I  FI  4 

Real 

Imaginary  part  of  normal  force  on  1  from  4 

RF12 

Real 

Real  part  of  normal  force  on  1  from  2 

IF12 

Real 

Imaginary  part  of  normal  force  on  1  from  2 

RF21 

Real 

Real  part  of  normal  force  on  2  from  1 

IF21 

Real 

Imaginary  part  of  normal  force  on  2  from  1 

523 


Created  3y: 
Notes: 


NAME 

TYPE/KEY 

DESCRIPTION 

RF23 

Real 

Real  part  of  normal  force  on  2  from  3 

IF23 

Real 

Imaginary  part  of  normal  force  on  2  from  3 

RF32 

Real 

Real  part  of  normal  force  on  3  from  2 

IF32 

Real 

Imaginary  part  of  normal  force  on  3  from  2 

RF34 

Real 

Real  part  of  normal  force  on  3  from  4 

IF34 

Real 

Imaginary  part  of  normal  force  on  3  from  4 

RF43 

Real 

Real  part  of  normal  force  on  4  from  3 

IF43 

Real 

Imaginary  part  of  normal  force  on  4  from  3 

RF4 1 

Real 

Real  part  of  normal  force  on  4  from  1 

IF4 1 

Real 

Imaginary  part  of  normal  force  on  4  from  1 

RK1 

Real 

Real  part  of  shear  panel  kick  force  at  1 

IK1 

Real 

Imaginary  part  of  shear  panel  kick  force  at 

1 

RS12 

Real 

Real  part  of  shear  force  1-2 

IS12 

Real 

Imaginary  part  of  shear  force  1-2 

RK2 

Real 

Real  part  of  shear  panel  kick  force  at  2 

IK2 

Real 

Imaginary  part  of  shear  panel  kick  force  at 

2 

RS23 

Real 

Real  part  of  shear  force  2-3 

IS23 

Real 

Imaginary  part  of  shear  force  2-3 

RK3 

Real 

Real  part  of  shear  panel  kick  force  at  3 

IK3 

Real 

Imaginary  part  of  shear  panel  kick  force  at 

3 

RS34 

Real 

Real  part  of  shear  force  3-4 

IS34 

Real 

Imaginary  part  of  shear  force  3-4 

RK4 

Real 

Real  part  of  shear  panel  kick  force  at  4 

IK4 

Real 

Imaginary  part  of  shear  panel  kick  force  at 

4 

RS41 

Real 

Real  part  of  shear  force  4-1 

IS4 1 

Real 

Imaginary  part  of  shear  force  4-1 

Module  EDR 


1.  This  relation  is  used  by  module  OFPEDR  for  output  printing  and  punching. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


EOSUMMRY 

Relation 

Contains  a  summary  of  the  element  output  requests. 


NAME 

TYPE/KEY 

DESCRIPTION 

BCID 

Integer  >  0 

Boundary  condition  identification  number 

NITER 

Integers  -1 

Iteration  step  for  output  (-1  for  all) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

Ttext  (8) 

Element  type  (example:  “ROD”) 

RECORD 

Integer  >  0 

Record  number  in  EODISC  unstructured 
entity  containing  related  data 

Module  PFBULK 


1.  For  each  BCID,  the  tuples  are  sorted  by  ETYPE  and  then  EID. 
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Entity: 

Entity ype; 
Description: 
Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

OAFLAG 

2  >  Integer  >  1 

Optimize/analyze  flag 
=1  Optimization 
=2  Analysis 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

BCID 

Integer  >  0 

Boundary  condition  identification  number 

DISC 

Integer  >  0 

Discipline  type 

=  1  Statics  =  5  Transien 

=  2  Modes  =  7  Buckling 

=  3  Steady  Aero  =  8  Blast 

SUBCASE 

Integer  >  0 

Subcase  identification  number  if  (DISC  = 

1,  3,  5,  8)  or  Mode  Number  if  (DISC  =  2,  7) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

String 

Element  type  (“TRIA3”) 

CMP  LX 

Integer  >  0 

Complex  output  identifier 
=  1  if  real  response  quantities 
=  2  if  complex  response  quantities 

LAYRNUM 

Integer  >  0 

Layer  number 

ESER 

Real 

Real  part  of  element  strain  energy 

ESEI 

Real 

Imaginary  part  of  element  strain  energy 

Z1 

Real 

Fiber  distance  1 

RSTRSX1 

Real 

Real  part  of  normal  stress  in  x-direction  at 

Z1 

ISTRSX1 

Real 

Imaginary  part  of  normal  stress  in  x- 
direction  at  Z1 

RSTRSY1 

Real 

Real  part  of  stress  in  y-direction  at  Z1 

ISTRSY1 

Real 

Imaginary  part  of  stress  in  y-direction  at  Z1 

RSSXY1 

Real 

Real  part  of  shear  stress  at  Z1 

ISSXY1 

Real 

Imaginary  part  of  shear  stress  at  Z1 

ANGLES 1 

Real 

Principal  angle  for  stress  at  Z1 

STRS11 

Real 

Major  principal  stress  at  Z1 

STRS12 

Real 

Minor  principal  stress  at  Z1 

MAXSS1 

Real 

Maximum  shear  stress  at  Z1 

EOTRIA3 

Relation 

Contains  the  element  response  quantities  for  the  TRIAS  element. 
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NAME 

TYPE/KEY 

DESCRIPTION 

Z2 

Real 

Fiber  distance  2 

RSTRSX2 

Real 

Real  part  of  stress  in  x-direction  at  Z2 

ISTRSX2 

Real 

Imaginary  part  of  stress  in  x-direction  at  Z2 

RSTRSY2 

Real 

Real  part  of  stress  in  y-direction  at  Z2 

ISTRSY2 

Real 

Imaginary  part  of  stress  in  y-direction  at  Z2 

RSSXY2 

Real 

Real  part  of  shear  stress  at  Z2 

ISSXY2 

Real 

Imaginary  part  of  shear  stress  at  Z2 

ANGLES2 

Real 

Principal  angle  for  stress  at  Z2 

STRS21 

Real 

Major  principal  stress  at  Z2 

STRS22 

Real 

Minor  principal  stress  at  Z2 

MAXSS2 

Real 

Maximum  shear  stress  at  Z2 

RSTRNX1 

Real 

Real  part  of  strain  in  x-direction  at  Z1 

ISTRNX1 

Real 

Imaginary  part  of  strain  in  x-direction  at  Z1 

RSTRNY1 

Real 

Real  part  of  strain  in  y-direction  at  Z1 

ISTRNY1 

Real 

Imaginary  part  of  strain  in  y-direction  at  Z1 

RSNXY1 

Real 

Real  part  of  shear  strain  at  Z1 

ISNXY1 

Real 

Imaginaryl  part  of  shear  strain  at  Z1 

ANGLEN1 

Real 

Principal  axis  angle  at  Z1 

STRN11 

Real 

Major  principal  strain  at  Z1 

STRN12 

Real 

Minor  principal  strain  at  Z1 

MAXNS1 

Real 

Maximum  shear  strain  at  Z1 

RSTRNX2 

Real 

Real  part  of  strain  in  x-direction  at  Z2 

ISTRNX2 

Real 

Imaginary  part  of  strain  in  x-direction  at  Z2 

RSTRNY2 

Real 

Real  part  of  strain  in  y-direction  at  Z2 

ISTRNY2 

Real 

Imaginary  part  cf  strain  in  y-direction  at  Z2 

RSNXY2 

Real 

Real  part  of  shear  strain  at  Z2 

ISNXY2 

Real 

Imaginary  part  of  shear  strain  at  Z2 

ANGELN2 

Real 

Principal  axis  angle  at  Z2 

STRN21 

Real 

Major  principal  strain  at  Z2 

STRN22 

Real 

Minor  principal  strain  at  Z2 

MAXSN2 

Real 

Maximum  shear  strain  at  Z2 

RMEMX 

Real 

Real  part  of  membrane  force  in  x-direction 

Created  By: 
Notes: 


NAME 

TYPE/KEY 

DESCRIPTION 

IMEMX 

Real 

Imaginary  part  of  membrane  force  in  x- 
direction 

RMEMY 

Real 

Real  part  of  membrane  force  in  ^-direction 

IMEMY 

Real 

Imaginary  part  of  membrane  force  in  y- 
direction 

RMEMXY 

Reai 

Real  part  of  membrane  force  in  xy-plane 

IMEMXY 

Real 

Imaginary  part  of  membrane  force  in  xy- 
plane 

RBENDX 

Real 

Real  part  of  bending  moment  in  x-direction 

IBENDX 

Real 

Imaginary  part  of  bending  moment  in  x- 
direction 

RBENDY 

Real 

Real  part  of  bending  moment  in  ,y-direction 

I BENDY 

Real 

Imaginary  part  of  bending  moment  in  y- 
direction 

RBENDXY 

Real 

Real  part  of  bending  moment  in  xy-plane 

IBENDXY 

Real 

Imaginary  part  of  bending  moment  in  xy- 
plane 

RSHEARX 

Real 

Real  part  of  shear  force  in  x-direction 

ISHEARX 

Real 

Imaginary  part  of  shear  force  in  x-direction 

RSHEARY 

Real 

Real  part  of  shear  force  in  y-direction 

ISHEARY 

Real 

Imaginary  part  of  shear  force  in  y-direction 

Module  EDR 

1.  This  relation  is  used  by  module  OFPEDR  for  output  printing  and  punching. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

OAFLAG 

2  >  Integer  >  1 

Optimize/analyze  flag 
=1  Optimization 
=2  Analysis 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

BCID 

Integer  >  0 

Boundary  condition  identification  number 

DISC 

Integer  >  0 

Discipline  type 

=  1  Statics  =  5  TYansien 

=  2  Modes  -  7  Buckling 

=  3  Steady  Aero  =  8  Blast 

SUBCASE 

Integer  >  0 

Subcase  identification  number  if  (DISC  = 

1,  3,  5,  8)  or  Mode  Number  if  (DISC  =  2,  7) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

String 

Element  type  (“ThMEM”) 

CMPLX 

Integer  >  0 

Complex  output  identifier 
=  1  if  real  response  quantities 
=  2  if  complex  response  quantities 

LAYRNUM 

Integer  >  0 

Layer  number 

ESER 

Real 

Real  part  of  element  strain  energy 

ESEI 

Real 

Imaginary  part  of  element  strain  energy 

RSTRSX 

Real 

Real  part  of  normal  stress  in  x-direction 

ISTRSX 

Real 

Imaginary  part  of  normal  stress  in  x- 
direction 

RSTRSY 

Real 

Real  part  of  normal  stress  in  y-direction 

I3TRSY 

Real 

Imaginary  part  of  normal  stress  in  y- 
direction 

RSTRSS 

Real 

Real  part  of  shear  stress 

ISTRSS 

Real 

Imaginary  part  of  shear  stress 

THSTRS 

Real 

Principal  angle  for  stress 

STRS1 

Real 

M^jor  principal  stress 

STRS2 

Real 

Minor  principal  stress 

MS SIRS 

Real 

Maximum  shear  stress 

RSTRNX 

Real 

Real  part  of  normal  strain  in  x-direction 

EOTRMEM 

Relation 

Contains  the  element  response  quantities  for  the  TRMEM  element. 
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Created  By: 
Notes: 


NAME 

TYPE/KEY 

DESCRIPTION 

ISTRNX 

Real 

Imaginary  part  of  normal  strain  in  x- 
direction 

RSTRNY 

Real 

Real  part  of  normal  strain  in  y-direction 

ISTRNY 

Real 

Imaginary  part  of  normal  strain  in  y- 
direction 

RSTRNS 

Real 

Real  part  of  shear  strain 

ISTRNS 

Real 

Imaginary  part  of  shear  strain 

THSTRN 

Real 

Principal  angle  for  strain 

STRN1 

Real 

Major  principal  strain 

STRN2 

Real 

Minor  principal  atrain 

MSSTRN 

Real 

Maximum  shear  strain 

RFX 

Real 

Real  part  of  force  in  x-direction 

IFX 

Real 

Imaginary  part  of  force  in  x-direction 

RFY 

Real 

Real  part  of  force  in  y-direction 

IFY 

Real 

Imaginary  part  of  force  in  y-direction 

RFXY 

Real 

Real  part  of  shear  force  in  xy-plane 

IFXY 

Real 

Imaginary  part  of  shear  force  in  xy-plane 

Module  EDR 

1.  This  relation  is  used  by  module  OFPEDR  for  output  printing  and  punching. 
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Entity; 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


E POINT 
Relation 

Contains  the  identification  numbers  of  those  points  to  be  used  as  extra  points.  In¬ 
put  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Extra  point  set  identification  number 

EXT  ID 

Integer  >  0 

Extra  point  identification  number 

Module  IFP 


FFT 

Relation 

Contains  the  parameters  required  for  controlling  the  Fast  Fourier  Transforma¬ 
tion  as  input  from  the  Bulk  Data  file 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer  >  0,  key 

FFT  set  identification  number 

TIME 

Real  >  0 

Length  of  time  period 

NT 

Integer  >  2 

Number  of  time  points 

RDELTF 

Real 

Ratio  of  frequency  range  increment  to 
1/TIME 

RF 

Real 

Ratio  of  frequency  range  to  NT/2*TIME 

FRIM 

Text (8) 

Frequency  interpolation  method 

OTYPE 

Tfext  (8) 

Types  of  response  output 

FLIM 

Tfext  (8) 

Frequency  load  interpolation  method 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


FLFACT 

Relation 

Contains  flutter  aerodynamic  input  data  as  defined  on  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

VALUE 

Real 

Data  value 

Module  1FP 

1.  This  relation  contains  one  tuple  for  each  value  in  each  set  defined  on  the 
FLFACT  entry. 

FLUTMODE 

Matrix 

A  matrix  used  to  store  the  complex  modal  participation  factors  for  any  flutter 
eigenvectors  computed  during  flutter  analyses  in  analysis  boundary  conditions. 

A  complex  rectangular  matrix  with  one  row  for  each  normal  mode  (including 
those  omitted  from  the  flutter  analysis)  and  one  column  for  each  flutter  eigenvec¬ 
tor  found  in  the  current  boundary  condition. 

FLUTTRAN 

1.  The  FLUTREL  entity  contains  additional  data  to  identify  the  flutter  condi¬ 
tion  for  each  mode. 

2.  This  entity  is  flushed  between  each  analysis  boundary  condition  having  flut¬ 
ter  analyses. 

3.  This  entity  is  not  used  in  the  optimization  boundary  conditions. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


FLUTREL 

Relation 

Contains  the  flutter  results  for  each  flutter  engenvector/eigenvalue  found  during 
flutter  analyses. 


NAME 

TYPE/KEY 

DESCRIPTION 

SUBID 

Integer  >  0 

Flutter  subcase  identification  number 

COLUMN 

Integer  >  0 

Column  number  in  FLUTMODE  for 
corresponding  participation  factors 

MACH 

Real 

Flutter  Mach  number 

RHORATIO 

Real  >  0 

Flutter  density  ratio 

RFRQ 

Real  >  0 

Flutter  reduced  frequency 

VEL 

Real 

Flutter  velocity 

RHOREF 

Real  >  0 

Reference  density 

REFCHORD 

Real  >  0 

Reference  chord  length 

Module  FLUTTRAN 


1.  This  entity  is  used  to  print  the  flutter  mode  shapes  in  physical  coordinates. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


FLUTTER 

Relation 

Contains  the  definition  of  data  needed  to  perform  fluwr  analyses  as  input  from 
the  bulk  data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

METHOD 

Tbxt  (4) 

Flutter  analysis  method  =  K,  PK  or  KE 

DENS 

Integer  >  0 

Identification  of  FLFACT  tuples  defining 
density  ratios 

MACHVAL 

Real  >  0.0 

Mach  number  to  be  used  in  the  Flutter  analyses 

VEL 

Integer  >  0 

Identification  of  FLFACT  tuples  specifying 
velocities 

MLIST 

Integer 

Identification  number  of  SET1  entries  listing 
the  normal  modes  to  be  omitted  in  the  flutter 
analysis 

KLIST 

Integer 

Identification  of  FLFACT  tuples  specifying  a 
list  of  “hard  point”  reduced  frequencies  for  the 
given  Mach  number  for  use  in  the  Flutter 
analysis 

EFFID 

Integer 

Identification  of  a  CONEFFF  set  specifying 
control  surface  effectiveness  values 

SYMXZ 

Integer 

Symmetry  flag  for  xz-plane 

SYMXY 

Integer 

Symmetry  flag  for  xy-plane 

EPS 

Real 

Convergence  parameter  for  flutter  eigenvalue 

CURVFIT 

Ifext(8) 

Type  of  curve  fit  to  be  used  in  the  PK  flutter 
analysis 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


FORCE 


Relation 

Contains  the  definition  of  a  static  load  at  a  grid  point  as  input  from  the  Bulk 
Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

GRID1 

Integer  >  0 

Grid  point  at  which  the  load  is  applied 

CID1 

Integer  2: 0 

Coordinate  system  identification 

SCALE 

Real 

Scale  factor 

Nl,  N2,  N3 

Real 

Components  of  the  force  vector 

Module  iEP 

FORCE 1 
Relation 

Contains  the  definition  of  a  load  applied  at  a  grid  point  with  the  direction  deter¬ 
mined  by  a  line  connecting  two  grid  points. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

GRID1 

Integer  >  0 

Grid  point  id  at  which  the  force  is  applied 

SCALE 

Real 

Scale  factor 

GRID2,  GRID3 

Integer  >  0 

Grid  point  identification 

Module  IFP 


535 


Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


FREQ 

Relation 

Contains  frequency  values  to  be  used  for  solution  in  frequency  response. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer  >  0 

Set  identification  number 

FREQ 

Real 

Frequency  value 

Module  IFP 

1.  The  relation  is  used  in  subroutine  PREFRQ  in  the  generation  of  the  FREQL 
entity. 

2.  The  unit  for  FREQ  is  Hertz. 

3.  The  set  is  selected  in  Solution  Control. 

FREQ1 

Relation 

Contains  information  to  specify  frequencies  used  in  frequency  response  solution 
as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer  >  0 

Set  identification  number 

FI 

Real  >  0.0 

First  frequency  in  a  set 

DFRQ 

Real  >  0.0 

Frequency  increment 

NDFR 

Integer 

Number  of  increments 

Module  IFP 

1.  The  relation  is  used  in  subroutine  PREFRQ  in  the  generation  of  the  FREQL 
entity. 

2.  Units  for  FI  and  DFREQ,  when  input,  are  Hertz. 

3.  The  set  is  selected  in  Solution  Control. 
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Entity:  FREQ2 

Entity  Type:  Relation 

Description:  Contains  information  to  specify  frequencies  used  in  frequency  response  solution 

as  input  from  the  Bulk  Data  file. 

Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer  >  0 

Set  identification  number 

FI 

Real  >  0.0 

First  frequency  value 

F2 

Real  >  0.0,  F2  >  FI 

Last  frequency  value 

NLOGI 

Integer  >  0 

Number  of  increments 

Created  By:  Module  IFP 

Notes: 

1.  The  relation  is  used  in  subroutine  PREFRQ  in  the  generation  of  the  FREQL 
entity. 

2.  Units  for  FI  and  F2,  when  input,  are  Hertz. 

3.  The  set  is  selected  in  Solution  Control. 


Entity: 

FREQL 

Entity  Type: 

Unstructured 

Description: 

Contains  a  list  of  frequencies  for  each  frequency  set. 

Record: 

1.  Contains  a  list  of  the  LIDs  of  the  frequency  sets  in  the  Bulk  Data  file, 
i.  Contains  the  frequency  list  for  the  (i-l)th  set  ID. 

Created  By: 

Notes: 

Module  FFBULK 

1.  This  entity  is  used  in  the  generation  of  frequency  dependent  loads  in  the 
DMA  module. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 
Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 

Entity: 
Entity  Type: 
Description: 


Matrix  Form: 

Created  By: 
Notes: 


FREQLIST 

Relation 

Contains  the  list  of  frequencies  for  which  outputs  are  requested  as  input  from 
the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer 

Set  identification  number 

FREQ 

Real 

Frequency  value  in  Hertz. 

Mobile  IFP 

FTF 

Matrix 

A  matrix  used  in  the  nuclear  blast  response  calculation  to  compute  the  forces  on 
structural  modes  given  the  forces  at  the  aerodynamic  panels. 

A  real,  rectangular  matrix  with  the  number  of  rows  equal  to  the  number  of  aero¬ 
dynamic  panels. 

MAPOL 

1.  FTF  is  computed  using: 

[FTF]  =  [PHIB]'1'  *  [BLGTJA] 

GASUBO 

Subscripted  Matrix 
Contains  the  matrix  product: 

-  [K&OC  ]_1  [KAOA  ] 

used  in  the  static  reduction  of  the  free  degrees  of  freedom.  This  matrix  includes 
the  aeroelastic  terms. 

A  variable-sized  matrix  haring  one  row  for  each  omitted  degree  of  freedom  and 
one  column  for  each  degree  of  freedom  in  the  analysis  set  for  the  current  bound¬ 
ary  condition. 

MAPOL 

1.  The  dimension  of  this  subscripted  matrix  must  be  large  enough  for  all  optimi¬ 
zation  and  analysis  boundary  conditions. 
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Entity: 

Entity  Typ :: 
Descnption: 

Relation  Attributes: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 


GDVLIST 

Relation 

Contains  the  definition  of  the  list  of  global  design  variables  as  input  from  the 
Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer 

Set  identification  number 

DVID 

Integer 

Global  design  variable  identification 

Module  IFP 

GENFA 

Matrix 

The  generalized  force  matrix  form  of  the  MATSS  matrix  developed  for  nuclear 
blast  response. 

Real  rectangular  matrix  with  the  number  of  rows  equal  to  the  number  of  modes 
retained  for  the  blast  analysis  and  the  number  of  columns  equal  to  the  number  of 
panels  in  the  unsteady  aerodynamics  model. 

Module  MAPOL 

GENF 

Matrix 

The  generalized  matrix  form  of  the  BFRC  matrix  developed  for  nuclear  blast  re¬ 
sponse. 

Real  rectangular  matrix  with  the  number  of  rows  equal  to  the  number  of  modes 
retained  for  the  blast  analysis  and  three  columns. 

Module  MAPOL 

GENK 

Matrix 

The  generalized  matrix  form  of  the  KAA  matrix  developed  for  nuclear  blast  re¬ 
sponse. 

Real  square  matrix  with  the  number  of  rows  equal  to  the  number  of  modes  re¬ 
tained  for  the  blast  analysis. 

Module  MAPOL 
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Entity: 
Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 
Entity  Type: 
Description: 

Entity: 
Entity  Type: 
Description: 


GENM 

Matrix 

The  generalized  matrix  form  of  the  MAA  matrix  developed  for  nuclear  blast  re¬ 
sponse. 

Real  square  matrix  with  the  number  of  rows  and  columns  equal  to  the  number  of 
modes  retained  for  the  blast,  analysis. 

Module  MAPOL 

GENQL 

Matrix 

The  generalized  matrix  form  of  the  MATTR  matrix  developed  for  nuclear  blast  re¬ 
sponse. 

Real  rectangular  matrix  with  the  number  of  rows  equal  to  the  number  of  modes 
retained  for  the  blast  analysis  and  the  number  of  columns  equal  to  the  number  of 
panels  in  the  unsteady  aerodynamics  model  times  the  number  of  beta  values  used 
in  the  fitting  process. 

Module  MAPOL 

GENQ 

Matrix 

The  generalized  matrix  form  of  the  MATSS  matrix  developed  for  nuclear  blast  re¬ 
sponse. 

Real  square  matrix  with  the  number  of  rows  equal  to  the  number  of  modes  re¬ 
tained  for  the  blast  analysis  and  the  number  of  columns  equal  to  the  number  of 
panels  in  the  unsteady  aerodynamics  model  times  the  number  of  beta  values  used 
in  the  fitting  process. 

Module  MAPOL 


GFE 


Matrix 

A  partition  of  the  GENF  matrix  (see  GENF). 

GFR 

Matrix 

A  partition  of  the  GENF  matrix  (see  GENF). 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


GEOMSA 

Relation 

Contains  data  on  the  geometric  location  of  the  aerodynamic  degrees  of  freedom 
for  the  planar  and  nonplanar  steady  aerodynamics  models. 


NAME 

TYPE/KEY 

DESCRIPTION 

MODEL 

Integer 

Planar  or  nonplanar  steady  aerodynamics 
model  identifier 
=  1  for  planar  model 
=  -  2  for  nonplanar  model 

MACROID 

Integer 

Component  identification  number 

ACMPNT 

'Ifext  (8) 

Component  type 

One  of  WING,  FIN,  CANARD,  POD,  or  FUSEL 

NDOF 

Integer 

Number  of  degrees  of  freedom  at  the  point. 

=  1  for  all  steady  aerodynamic  boxes 

refer  to  GEOMUA  for  unsteady  model  options. 

EXTID 

Integer 

External  box  identification  number 

INTID 

Integer 

Internal  box  identification  number.  This  is  the 
row  and/or  column  number  in  the  AICMAT 

AREA 

Real 

The  area  of  the  box. 

X 

Real 

The  x  location  of  the  box  centroid  in  basic 
coordinates. 

Y 

Real 

The  y  location  of  the  box  centroid  in  basic 
coordinates. 

Z 

Real 

The  z  location  of  the  box  centroid  in  basic 
coordinates. 

N1 

Real 

The  x  component  of  the  box  normal  in  basic 
coordinates. 

N2 

Real 

The  y  component  of  the  box  normal  in  basic 
coordinates. 

N3 

Real 

The  z  component  of  the  box  normal  in  basic 
coordinates. 

R1 

Real 

The  x  component  of  the  box  lotation  axis  in 
basic  coordinates. 

R2 

Real 

The  y  component  of  the  box  rotation  axis  in 
basic  coordinates. 

R3 

Real 

The  z  component  of  the  box  rotation  axis  in 
basic  coordinates. 

Created  By:  Module  STEADY  and  STEADYNP 

Notes: 

1.  These  data  are  used  in  splining  the  aerodynamic  forces  to  the  structural 
model,  in  splining  structural  deflections  to  the  aerodynamic  model  and  in  re¬ 
covering  trimmed  pressures  and  displacements  on  the  aerodynamic  model. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


GEOMUA 

Relation 

Contains  data  on  the  geometric  location  of  the  aerodynamic  degrees  of  freedom 
for  the  unsteady  aerodynamics  models.  Two  entries  are  loaded  for  ZY  boxes  to  ac¬ 
count  for  the  two  normals  during  splining. 


NAME 

TYPE/KEY 

DESCRIPTION 

MACROID 

integer 

Component  identification  number 

ACMPNT 

Tfext  (8) 

Component  type 

One  of  WING,  FIN,  CANARD,  POD,  or  FUSEL 

NDOF 

Integer 

Number  of  degrees  of  freedom  at  the  point. 

=  1  for  all  lifting  surface  boxes  CAEROl 
=  2  for  all  body  surface  boxes  CAER02 

EXT  ID 

Integer 

External  box  identification  number 

INTID 

Integer 

Internal  box  identification  number. 

AREA 

Real 

The  area  of  the  box. 

X 

Real 

The  x  location  of  the  box  centroid  in  basic 
coordinates. 

Y 

Real 

The  y  location  of  the  box  centroid  in  basic 
coordinates. 

Z 

Real 

The  z  location  of  the  box  centroid  in  basic 
coordinates. 

Nl 

Real 

The  x  component  of  the  box  normal  in  basic 
coordinates. 

N2 

Real 

The  y  component  of  the  box  normal  in  basic 
coordinates. 

N3 

Real 

The  z  component  of  the  box  normal  in  basic 
coordinates. 

R'l 

Real 

The  x  component  of  the  box  rotation  axis  in 
basic  coordinates. 

R2 

Real 

The  y  component  of  the  box  rotation  axis  in 
basic  coordinates. 

R3 

Real 

The  z  component  of  the  box  rotation  axis  in 
basic  coordinates. 

Mor’ul UNSTEADY 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 
Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


GGO 

Matrix 

Rigid  body  transformation  matrix  to  transfer  displacements  at  the  origin  of  the 
basic  coordinate  system  to  g-set  displacements. 

Real  rectangular  matrix  with  g-set  rows  and  up  to  six  columns. 

Module  GDR1 

GLBDES 

Relation 

Contains  current  design  variable  information  for  all  design  variables  in  the  prob¬ 
lem. 


NAME 

TYPE/KEY 

DESCRIPTION 

NITER 

Integer 

Iteration  number 

DOBJ 

Real 

Sensitivity  of  the  objective  to  the  design 
variable 

DVID 

Integer  >  0,  key 

Design  variable  identification  number 

OPTION 

Integer  1,  2, 3 

Design  variable  linking  option 

LINKID 

Integer 

Link  set  identification 

EID 

Integer  >  0 

Element  id  if  design  variable  uniquely 
linked  to  one  element 

ETYPE 

Text (8) 

Element  type  if  unique  linking 

LAYRNUM 

Integer 

Layer  number  if  unique  or  physical  linking 

LAYRLST 

Integer 

PLYLIST  identifier  if  multiple  plies  are 
linked  together 

VMIN 

Real 

Minimum  value  for  design  variable 

VMAX 

Real 

Maximum  value  for  design  variable 

VALUE 

Real 

Current  value  of  design  variable 

LABEL 

Text (8) 

User  identification  label 

Module  MAKEST,  DOBJ  is  computed  in  EMA 


1.  The  linking  options  are: 

OPTION  =  1  DESELM  linking 
OPTION  =  2  DESVARP  linking 
OPTION  =  3  DESVARS  linking 

2.  Design  variable  offset  is  stored  in  INFO(ll)  from  MAKEST.  The  value  is 
transferred  to  DVCT  in  the  EMG  module.  The  offset  is  used  to  generate 
pseudo  design  variables  to  control  the  bending  behavior  of  designed  CBAR 
elements. 
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Entity: 
Entity  Type: 
Description: 

Matrix  Form: 


Created  By: 
Notes: 


GLBSIG 

Matrix 

Contains  the  stress  and  strain  components  in  the  element  coordinate  system  for 
elements  constrained  through  stress/strain  constraint  bulk  iJata  entries. 

A  variable-size  matrix  having  one  row  for  each  stress/strain  component  for  each 
element  subject  to  a  strength  constraint  and  one  column  for  each  load  condition 
within  each  boundary  condition.  The  order  of  the  matrix  rows  is  in  element  id  or¬ 
der  of  constrained  elements  within  each  element  type.  The  element  types  are  cur¬ 
rently  processed  in  the  following  order: 

(1)  BAR;  °al,  aa2,  °a3,  °a4,  °bl,  CTb2,  ab3,  °b4 

(2)  QDMEM1;  ax,  °y.  V 

(3)  QUAD4;  cx,  °y,  Txy 

(4)  ROD;  ax,  xxy 

(5)  SHEAR;  Txy 

(6)  TRIA3;  °x,  °y,  Txy 

(7)  TRMEM;  cx,  °y,  Txy 

The  columns  are  processed  in  load  condition  order  for  each  boundary  condition. 
Module  SCEVAL 

1.  If  no  elements  are  constrained,  this  matrix  will  be  empty. 

2.  Refer  to  the  SMAT  documentation  for  further  details  as  GLBSIG  is  essen¬ 
tially: 

[SMAT  ]fc  [Ug  ] 

3.  Each  boundary  condition’s  load  conditions  are  appended  onto  the  existing 
GLBSIG  columns  within  the  SCEVAL  module. 
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GMKCT 

Relation 


Entity: 

Entity  Type: 

Description:  Contains  data  required  to  interpret  the  DKVI  unstructured  entity  for  the  purpose 

of  assembling  the  global  stiffness  matrix.  The  relation  is  sorted  by  DVID  and 
KSIL. 

Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

DVID 

Integer  >  0 

Design  variable  identification 

KSIL 

Integer  >  0 

Internal  id  of  grid  or  scalar  point 
connected  to  the  design  variable 

KCODE 

Integer  >  0 

Codeword  denoting  the  form  in  which  the 
DKVI  data  are  stored 

NODES 

Integer  0  <  NODES  < 

20 

Number  of  nodes  being  processed  with 
this  KSIL 

IREC 

Integer  >  0 

Record  number  of  DKVI  entity  where 
data  are  stored 

ASIL 

Ivector  (20) 

List  of  associated  SILS 

ALPHA 

Real 

Exponential  power  associated  with  BAR 
element  design  variable 

Created  By:  Module  EMA1 

Notes: 

1.  KCODE  definitions: 

=  1  Multiple  associated  grids  with  both  extensional  and  rotational 

degrees  of  freedom. 

=  2  Column  being  assembled  is  a  scalar  point.  Associated  SILS 

may  or  may  not  be  scalar  points. 

=  3  Column  being  assembled  is  a  grid  point.  At  least  one  row  is  a 

scalar  point. 

=  4  Only  extensional  degrees  of  freedom  are  included  in  the  as¬ 

sembly  process 

2.  The  INFO  array  for  this  entity  contains  additional  memory  management  allo¬ 
cation  data: 

ENFO(ll)  -  The  number  of  tuples  connected  to  the  zeroth  design 

variable. 

INFO(12)  -  The  maximum  number  of  tuples  connected  to  any  one  of 

the  remaining  design  variables. 
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Entity: 

Entity  Type: 
Description. 

Relation  Attributes: 


Created  By: 
Notes: 


GMMCT 

Relation 

Contains  data  required  to  interpret  the  DMVI  unstructured  entity  for  the  pur¬ 
pose  of  assembling  the  global  mass  matrix.  The  relation  is  sorted  by  DVID  and 
KSIL. 


NAME 

TYPE/KEY 

DESCRIPTION 

DVID 

Integer  >  0 

Design  variable  identification 

KSIL 

Integer  >  0 

Internal  id  of  grid  or  scalar  point 
connected  to  the  design  variable 

MCODE 

Integer  >  0 

Codeword  denoting  the  form  in  which  the 
DMVI  data  are  stored 

NODES 

Integer  0  <  NODES  < 

20 

Number  of  nodes  being  processed  with 
this  KSIL 

IREC 

Integer  >  0 

Record  number  of  DMVI  entity  where 
data  are  stored 

ASIL 

Ivector  (20) 

List  of  associated  SILS 

ALPHA 

Reai 

Exponential  power  associated  with  BAR 
element  design  variable 

Module  EMA1 

1.  MCODE  definitions: 

=  1  Multiple  associated  grids  with  both  extensional  and  rotational 

degrees  of  freedom. 

=  2  Column  being  assembled  is  a  scalar  point.  Associated  SILS 

may  or  may  not  be  scalar  points. 

=  3  Column  being  assembled  is  a  grid  point.  At  least  one  row  is  a 

scalar  point. 

=  4  Only  extensional  degrees  of  freedom  are  included  in  the  as¬ 

sembly  process. 

2.  The  INFO  array  for  this  entity  contains  additional  memory  management  allo¬ 
cation  data: 

INFO(ll)  -  The  number  of  tuples  connected  to  the  zeroth  design 

variable. 

INFO(  12)  -  The  maximum  number  of  tuples  connected  to  any  one  of 

the  remaining  design  variables. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


GPFDATA 

Relation 

Contains  the  grid  point  forces. 


NAME 

TYPE/KEY 

DESCRIPTION 

BC 

Integer  >  0 

Boundary  condition  identification  number 

NITER 

Integer  >  0 

Iteration  number  for  optimization 

DISC 

Integei  >  0 

Discipline  type 

=  1  Statics  =  5  Transient 

=  2  Modes  =  7  Buckling 

=  3  Steady  Aero  =  8  Blast 

SUBCASE 

Integer  >  0 

Subcase  identification  number  if  (DISC  =  1: 3, 
u,  8)  or  Mode  Number  if  (DISC  =  2,  7) 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

Ttext(8) 

Element  type  (example:  “BAR”) 

CMPLX 

Integer  >  0 

Complex  output  identifier 
=  1  if  real  response  quantities 
=  2  if  complex  response  quantities 

SIL 

Integer  >  0 

Internal  grid  point  identification  number 

FLAG 

Integer  >  0 

Flag  indicating  the  point  is  a  grid  point  or  a 
scalar  point 

RFORCE 

Real  vector(6) 

Real  parts  of  force  components 

I FORCE 

Real  vector(6) 

Imaginary  parts  of  force  components 

Module  EDR 

1.  This  relation  is  used  by  module  OFPEDR  for  output  printing  and  punching. 

2.  The  FLAG  equals  6  if  the  point  is  a  grid  point  and  equals  1  if  a  scalar  point 
and  0  if  not  in  the  g-set. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


GPFELEM 

Relation 

Contains  the  list  of  elements  connected  to  structural  nodes  for  which  grid  point 
forces  have  been  requested. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer  >  0 

Set  identification  number  of  GPFORCE  print 
request 

ETYPE 

Tfext(8) 

Element  type  (example:  “BAR”) 

EID 

Integer  >  0 

Element  identification  number 

NGRID 

Integer  >  0 

Number  of  grid  points  in  the  element  for  which 
grid  point  forces  are  needed 

AGRID 

Ivector  (32) 

Array  containing  sorted  list  of  GIDs 

Module  PFBULK 

1.  SID  refers  to  the  GRIDLIST  bulk  data  entry  used  in  the  GPFORCE  Solution 
Control  print  request  id  in  Solution  Control. 


GPWGGRID 

Relation 

Contains  the  definition  of  a  location  for  grid  point  weight  generation  as  input  by 
the  GPWG  data  entry  in  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

GRIDPNT 

Integer 

Grid  point  identification  or  NULL  if 
explicit  location  is  given 

XO 

Real 

x  location  of  the  point 

YO 

Real 

y  location  of  the  point 

ZO 

Real 

z  location  of  the  point 

Module  IFP 

1.  GRIDPNT  and  X0,Y0,Z0  are  mutually  exclusive  mechanisms  to  enter  a  loca- 
ucn 

2.  Only  the  first  tuple  of  GPWGGRID  will  be  used 

3.  If  no  tuples  exist,  t’'e  GPWG  is  performed  at  the  origin  of  the  basic  coordinate 
system 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


treated  By: 


GRADIENT 

Relation 

Contains  the  gradients  of  objective  and  constraint  gradients  requested  to  be 
printed  or  punched. 


NAME 

TYPE/KEY 

DESCRIPTION 

PRINTKEY 

Integer 

Key  value  referred  to  by  the  CONST 
relation 

DVID 

Integer 

Design  variable  identification  number 

GRADIENT 

Real 

Gradient  value  for  the  constraint  in 

CONST  with  the  associated  PRINTKEY 

Module  DESIGN  or  VANGO 

1.  This  entity  contains  one  tuple  for  every  global  design  variable  for  each  tuple 
of  CONST  with  a  nonzero  PRINTKEY  attribute.  That  attribute  points  to  the 
associated  tuples  of  this  entity. 

GRAV 

Relation 

Contains  the  definition  of  the  g — v^v  vectors  to  be  used  in  applying  gravity  load¬ 
ing  to  the  model. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

CID1 

Integer  >  0 

Coordinate  system  id 

SCALE 

Real 

Scale  factor 

Nl,  N2,  N3 

Real 

Components  of  the  gravity  vector 

Module  xFP 
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Entity; 

Entity  Type; 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

|  Relation  Attributes: 


Created  By: 


GRID 

Relation 

Contains  the  geometric  and  permanent  constraint  data  for  a  structural  grid  point 
as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

GRIDID 

Integer  >  0,  key 

The  external  grid  point  id 

CP 

Integer  k  0 

The  coordinate  system  in  which  the 
location  of  the  point  is  defined 

X,  Y,  Z 

Real 

The  location  of  the  grid  point 

CD 

Integer  >  0 

The  id  of  the  coordinate  system  to  be 
used  to  define  displacements, 
constraints,  degrees  of  freedom,  and 
solution  vectors 

PERMS PC 

Integer  >  0 

The  permanent  single  point  constraints 
associated  with  the  grid  point 

Module  IFF 

GRIDLIST 

Relation 

Contains  the  list  of  grid,  scalar  or  extra  points  for  wh’ch  node  dependent  outputs 
are  requested  as  input  from  the  Bulk  Data  file. 
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NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer 

Set  identification  number 

GID 

Integer 

External  grid/scalar/extra  point  identification 
number 

Module  IFP 


< 
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Entity: 
Entity  Type: 
Description: 


GRID TEMP 
Unstructured 


Contains  temperature  data  for  all  grid  and  scalar  points  for  all  thermal  load  sets 
defined. 

Recuid: 

i.  A  list  of  all  set  identification  numbers  in  sorted  order. 

i.  Contains  the  grid  and  scalar  point  temperatures  for  the  (i-l)th  specified  ther¬ 
mal  load  case.  The  storage  order  of  temperature  data  within  each  record  fol¬ 
lows  the  ordering  of  KSIL  values  in  the  BGPDT  table  with  extra  points 
excluded. 

Created  By.  PFBULK 

Notes: 

1.  This  entity  is  used  in  EMG  to  compute  average  element  temperatures  and  is 
used  in  LODGEN  to  compute  the  global  thermal  load  sensitivity  vectors. 


Entity: 

GSKF 

Entity  Type: 

Matrix 

Description: 

The  transpose  of  GSTKF  (see  GSTKG). 

Entity: 

GSTKF 

Entity  Ttype: 

Matrix 

Description: 

A  partition  of  the  GSTKN  matrix  (see  GSTKG) 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


GSTKG 

Matrix 

The  interpolation  matrix  relating  slopes  in  the  streamwise  direction  at  the  aero¬ 
dynamic  degrees  of  freedom  to  the  displacements  at  the  global  structural  degrees 
of  freedom. 

A  variable-sized  matrix  having  one  column  for  each  steady  aerodynamic  box  and 
one  row  for  each  structural  degree  of  freedom. 

Module  SPLINES 

1.  The  MAPOL  sequence  supports  the  following  partitions  of  the  GSTKG  matrix 
(see  the  Theoretical  Manual  for  the  explicit  formation  of  these  submatrices): 


GSKF  -■  [GSTKF  f 


Entity: 
Entity  Type: 
Description: 


GSTKN 

Matrix 

A  partition  of  the  GSTKG  matrix  (see  GSTKG). 


Entity: 

GSUBO 

Entity  Type: 

Subscripted  Matrix 

Description: 

See  Notes. 

Matrix  Form: 

A  variable-sized  matrix  with  one  row  for  each  omitted  degree  of  freedom  and  one 
column  for  each  degree  of  freedom  retained  for  analysis.  The  precision  of  this  ma¬ 
trix  is  the  same  as  that  of  the  KGG  matrix. 

Created  By: 

Notes: 

MAPOL 

1.  For  Guyan  reduction  GSUBO  contains  the  matrix  product 

-  [KOO  ]-1  [XOA  ] 

2.  If  no  omitted  degrees  of  freedom  are  defined  for  the  model,  GSUBO  will  be  in¬ 
itialized. 

3.  For  generalized  dynamic  reduction,  GSUBO  relates  degrees  of  freedom  in  the 
f-  to  q-  set  (union  of  a-,  k-,  and  j-sets)  degrees  of  freedom. 

Entity: 

GTKF 

Entity  Type: 

Matrix 

Description: 

A  partition  of  the  GTKN  matrix  (see  GTKN). 

Entity: 

GTKG 

Entity  Type: 

Matrix 

Description: 

The  interpolation  matrix  relating  the  forces  at  the  aerodynamic  degrees  of  free¬ 
dom  to  the  forces  at  the  global  structural  degrees  of  freedom. 

Matrix  Form: 

A  variable-sized  matrix  haring  one  column  for  each  steady  aerodynamic  degree  of 
freedom  (box)  and  one  row  for  each  structural  degree  of  freedom. 

Created  By: 

Notes: 

Module  SPLINES 

1.  The  MAPOL  sequence  creates  the  following  partitions  of  the  GTKG  matrix 
(see  the  Theoretical  Manual  for  the  explicit  formation  of  these  submatrices): 


GTKG  -4  JP. 

GTKN 

1 

GTKN  -4  I 

GTKF 
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Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


GTKN 


Matrix 

A  partition  of  the  GTKG  matrix  (see  GTKG). 

GUST 

Relation 

Contains  vertical  gust  data  for  a  gust  analysis  as  input  from  the  bulk  data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer  >  0 

Gust  set  ID 

GLOAD 

Integer  >  0 

ID  of  an  entry  which  defines  time  or  frequency 
dependent  loads. 

W  G 

Real  >  0.0 

Scale  factor  for  gust  velocity 

XO 

Seal  >  0.0 

Location  of  reference  plane  in  aerodynamic 
coordinates 

V 

Real  >  0 

Velocity  of  the  vehicle 

QDP 

Real  >  0 

Dynamic  pressure  of  the  vehicle 

MACH 

Real  £  0.0 

Mach  number  of  the  vehicle 

SYMXZ 

Integer 

Symmetry  flag  for  xz-plane 

SYMXY 

Integer 

Symmetry  flag  for  xy-lane 

Module  IFP 


IC 

Relation 

Contains  the  values  of  initial  displacements  and  velocities  for  use  in  direct  tran¬ 
sient  response  analysis  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer 

Set  identification  number 

GRID 

Integer 

Grid,  scalar  or  extra  point  identification 
number 

COMP 

Integer 

Grid  point  component  number 

uo 

Real 

Initial  displacement  yalue 

VO 

Real 

Initial  velocity  value 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Entity  Structure: 
Record: 


Created  By: 
Notes: 


Entity: 

Entity  'type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


ICDATA 

Unstructured 

Contains  the  collection  of  initial  condition  data  for  all  initial  condition  sets  refer¬ 
enced  in  Solution  Control. 


1.  A  list  of  all  set  identification  numbers  in  sorted  order, 
i.  Contains  the  initial  conditions  for  the  (i-l)th  initial  condition  set.  Each  record 
has  the  following  form: 


WORD 

VARIABLE 

DESCRIPTION 

1 

SID 

Set  identification 

i 

ROW 

Internal  number  of  the  degree  of  freedom  affected 
by  the  initial  condition  in  increasing  Row  order 

j+l to j+2 

For  each  degree  of  freedom  two  words  are  stored: 

(1)  initial  displacement 

(2)  initial  velocity 

PFBULK 

1.  This  entity  is  used  in  DMA  to  assemble  the  ICMATRIX  entity  for  the  bound¬ 
ary  condition. 

2.  The  j  index  runs  from  2  to  3  *  NROW  by  3  for  each  degree  of  freedom  in  the 
model  that  has  a  nonzero  initial  condition. 

ICMATRIX 

Matrix 

Contains  the  matrix  of  transient  response  initial  conditions  in  the  d-set  for  the 
current  boundary  condition. 

A  variable-sized  rectangular  matrix  having  one  row  for  each  degree  of  freedom  in 
the  d-aet  and  two  columns  for  each  transient  response  subcase.  The  first  column 
is  the  vector  of  initial  displacement  and  the  second  is  the  vector  of  initial  velocity. 

DMA 


1.  This  entity  will  be  Pushed  for  each  boundary  condition  having  dynamic  re¬ 
sponse  disciplines. 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 
Created  By: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 


Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


ID2 

Matrix 

An  identity  matrix  required  in  the  MAPOL  sequence  associated  with  the  nuclear 
blast  response. 

A  2  by  2  identity  matrix. 

Module  BLASTFIT 

IBM 

Subscripted  Matrix 

Intermediate  matrix  in  the  reduction  of  the  mass  matrix  for  unrestrained  bound¬ 
ary  conditions. 

The  number  of  rows  is  equal  to  the  number  of  degrees  of  freedom  in  the  o-set 
while  the  number  of  columns  is  equal  to  the  number  of  degrees  of  freedom  in  the 
a-set. 

MAPOL 

1.  If  there  are  no  aerodynamics,  IFM  is  computed  from  MOO  times  GSUBO  plus 
MOA. 

2.  If  there  are  aerodynamics,  IFM  is  computed  from  MOO  times  GASUBO  plus 
MOA. 

3.  Since  IFM  is  required  in  the  sensitivity  analysis,  it  is  subscripted  by  bound¬ 
ary  condition  number. 

IFR 

Subscripted  Matrix 

Intermediate  matrix  in  the  reduction  of  the  mass  matrix. 

The  number  of  rows  is  equal  to  the  number  of  degrees  of  freedom  in  the  1-set 
while  the  number  of  columns  is  equal  to  the  number  of  degrees  of  freedom  in  the 
r-set. 

MAPOL 

1.  IFR  is  computed  as  MLL  times  D  plus  MLR. 

2.  Since  IFS  is  required  in  the  sensitivity  anaysis,  it  is  subscripted  by  boundary 
condition  number. 
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Entity: 

Entity  Type: 
Description. 

Relation  Attributes: 


Created  By: 
Notes: 


IHEX1EST 


Relation 

Contains  the  element  summary  data  fi.r  the  linear  isoparametric  hexahedron  ele¬ 
ment. 


r~ — ~~ 

i  NAME 

- - - - 

TYPE/KEY 

DESCRIPTION 

SID 

Integer  >  0,  key 

Element  identification  number 

SILi 

1=1,2 .  .  .8 

Integer  >  0 

Internal  grid  points  identification  numbers 

COORDi 

1=1,2. . .8 

Integer  >  0 

External  coordinate  system  identification 
number  for  displacements  at  SILi 

Xi 

i=l, 2 ...  8 

Real 

Basic  coordinates  of  SIL>; 

Yi 

i=l, 2 . . .8 

Real 

Zi 

1=1, 2. . ,8 

Rea! 

MID 

Integer  >  0 

Material  identification  number 

CJD 

Integer  >  0 

Coordinate  system  identification  number 
in  which  anisotropic  material  is  defined. 

NIP 

Integer 

Number  of  integration  points  in  each  1 

coordinate  direction  j 

AR 

Real 

Maximum  aspect  ratio  of  element  ! 

ALFA 

Real 

Maximum  angle  (degrees)  for  face  normals  ! 

BETA 

Real 

Maximum  angle  (degrees)  for  mid-edge  ? 

points  I 

Module  MAKEST 

1.  This  relation  is  built  from  the  C3HEX,  the  P3HEX  and  the  basic  grid  point  re¬ 
lations.  It  contains  one  tuple  for  each  linear  isoparametric  hexahedron  ele¬ 
ment  in  the  problem. 
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Entity: 

Entity  Type: 
Description- 

Relation  Attributes: 


IHF.X2EST 

Relation 

Contains  the  element  summary  data  for  the  quadratic  isoparametric  hexahedron 
element. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

SILS 

Ivector  (20) 

Internal  grid  point  identification 
numbers 

COORDi 
i-1, 2. . .20 

Integer  >  0 

External  coordinate  system 
identification  number  for 
displacements  at  SILSi 

Xi 

i=l, 2 . . .20 

Rvector  (3) 

Basic  coordinates  of  SILSi 

MID 

Integer  >  0 

Material  identification  number 

CID 

Integer  >  0 

Coordinate  system  identification 
number  in  which  anisotropic  material 
is  defined 

NIP 

Integer  =  2,3,4 

Number  of  integration  points  in  each 
coordinate  direction 

AR 

Real 

Maximum  aspect  ratio  of  element 

ALFA 

Real 

Maximum  angle  (degrees)  for  face 
normals 

BETA 

Real 

Maximum  angle  (degrees)  for  mid-edge 
points 

Created  By: 
Notes: 


Module  MAKEST 

1.  This  relation  is  built  from  the  CIHEX,  the  PIHEX,  and  the  basic  grid  point  re¬ 
lations.  It  contains  one  tuple  for  each  quadratic  isoparametric  hexahedron 
element  in  the  problem. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

SILS 

Ivector  (32) 

Internal  grid  point  identification 
numbers 

COORDi 
i=l, 2 . . .32 

Integer  >  0 

External  coordinate  system 
identification  number  for 
displacements  at  SILSi 

Xx 

i=l, 2 . . .32 

Rvector  (3) 

Basic  coordinates  of  SILSi 

MID 

Integer  >  0 

Material  identification  number 

CID 

Integer  >  0 

Coordinate  system  identification 
number  in  which  anisotropic  material 
is  defined 

NIP 

Integer 

Number  of  integration  points  in  each 
coordinate  direction 

AR 

Real 

Maximum  aspect  ratio  of  element 

ALFA 

Real 

Maximum  angle  (degrees)  for  face 
normals 

BETA 

Real 

Maximum  angle  (degrees)  for  mid-  edge 
points 

IHEX3EST 

Relation 

Contains  the  element  summary  data  for  the  cubic  isoparametric  hexahedron  ele¬ 
ment. 


Created  By:  Module  MAKEST 

Notes: 

1.  This  relation  is  built  from  the  CIHEX,  the  PIHEX,  and  the  basic  grid  point  re¬ 
lations.  It  contains  one  tuple  for  each  quadratic  isoparametric  hexahedron 
element. 
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Entity: 

Entity  type: 
Description: 

Relation  Attributes: 


Created  By: 


ITERLIST 

Relation 

Contains  the  definition  of  the  list  of  design  iterations  as  input  from  the  Bulk 
Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer 

Set  identification  number 

NITER 

Integer 

Design  iteration  number 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


JOB 

Relation 

Contains  the  case-independent  solution  control  parameters  as  input  in  the  solu¬ 
tion  control  packet. 


NAME 

TYPE/KEY 

DESCRIPTION 

AIRFPRNT 

Integer 

vector 

(12) 

Airfoil  shape  print  selection 

WORD  1  Print  set  identification  number  >  0,  or 
=  0  NONE 
=  -l  ALL 
= -2  LAST 

WORD  2  Punch  set  identification  number 

WORD  3  Print  form 
=  0  Rectangular 
=  1  Polar 

WORD  4  Punch  form 

WORD  5  Print  frequency  set  identification  number 
WORD  6  Punch  frequency  set  identification  number 
WORD  7  Print  iteration  set  identification  number 
WORD  8  Punch  iteration  set  identification  number 
WORD  9  Print  mode  set  identification  number 
WORD  10  Punch  maode  set  identification  number 
WORD  11  Print  time  set  identification  number 
WORD  12  Punch  time  set  identification  number 

PLANPRNT 

Integer 

vector 

(12) 

Planfcrm  print  selection 

PRESPRNT 

Integer 

vector 

(12) 

Unit  pressure  coefficient  print  selection 

TITLE 

Tfext  (72) 

User  label  TITLE 

SUBTITLE 

Tbxt  (72) 

User  label  SUBTITLE 

LABEL 

Tfext  (72) 

User  label  LABEL 

Created  By: 
Notes: 


Module  Solution 

1.  fhe  format  of  the  AIRFPRNT  vector  is  typical  of  the  format  of  all  the  print  se¬ 
lection  vectors.  Additionally,  the  format  for  the  print  set  Identification  num¬ 
ber  in  the  AIRFPRNT  vector  is  typical  of  that  of  the  other  set  Identification 
numbers  in  the  vector. 

2.  The  CASE,  JOB  and  OPTIMIZE  relation  entities  together  contain  the  solu¬ 
tion  control  requests  as  input  in  the  solution  control  packet.  CASE  contains 
the  case-dependent  parameters,  JOB  contains  the  case-independent  requests 
and  OPTIMIZE  contains  the  optimization-dependent  requests. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity: 

Description: 

Relation  Attributes: 


Created  By: 
Notes: 

Entity:, 
Entity  Type: 
Description: 


JSET 

Relation 

Contains  the  external  grid  identification  numbers  and  components  with  the 
analysis  set  as  defined  on  the  JSET  entries  of  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

JSET  identification  number 

GRID1 

Integer  >  0 

Grid  or  Scalar  point  id 

COMPNTS 

Integer  >  0 

Component  number: 

=  0  for  scalar  points 

=  1-6  for  grid  points 

Module  IFP 

1.  Used  by  the  MKUSET  Module  to  build  the  USET  relation. 

JSET1 

Relation 

Contains  the  external  grid  identification  numbers  and  components  associated 
with  the  analysis  set  as  defined  on  the  JSET1  entries  of  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

JSET  identification  number 

COMPNTS 

Integer  >  0 

Component  number: 

=  0  for  scalar  points 

=  1-6  for  grid  points 

GRID1 

Integer  >  0 

Grid  or  Scalar  point  id 

Module  IFP 


1.  Used  by  the  MKUSET  Module  to  build  the  USET  relation. 

KAA 

Matrix 

Partition  of  the  KFF  matrix  (see  KGG). 
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Entity: 

KAAA 

Entity  Type: 

Matrix 

Description: 

Partition  of  the  KAFF  matrix  (see  KAFF). 

Entity: 

KAFF 

Entity  Type: 

Matrix 

Description: 

Contains  the  stiffness  matrix  for  the  free  degrees  of  freedom  in  the  current  bound¬ 
ary  condition  including  the  aeroelastic  terms. 

Matrix  Form: 

A  variable-sized  asymmetric  matrix  having  one  row  and  one  column  for  each  free 
degree  of  freedom  in  the  current  boundary  condition. 

Created  By: 

MAPOL 

Notes: 

1.  The  matrix  is  formed  using 

[  KAFF  ]  = 

=  [  KAFF ]  - 

q  (  AXCS  ] 

2.  The  MAPOL  sequence  supports  the  following  partitions  of  the  KAFF  matrix 
(see  the  Theoretical  Manual  for  the  explicit  formation  of  these  submatrices): 

KAFF  -> 

<P  1  ? 

KAO  |  KAAA 

KAAA  -> 

'  KARR  |  KARL  ' 
KALR  I  KALL 

Entity: 

KALL 

Entity  Type: 

Matrix 

Description: 

Partition  of  the  KAAA  matrix  (see  KAFF). 

Entity: 

KALR 

Entity  Type: 

Matrix 

Description: 

Partition  of  the  KAAA  matrix  (see  KAFF). 

Entity: 

KAO 

Entity  Type: 

Matrix 

Description: 

Partition  of  the  KAFF  matrix  (see  KAFF). 

Entity: 

KARL 

Entity  Type: 

Matrix 

Description: 

Partition  of  the  KAAA  matrix  (see  KAFF). 
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Entity: 

KARR 

Entity  Type: 

Matrix 

Description: 

Partition  of  the  KAAA  matrix  (see  KAFF). 

Entity: 

KDDF 

Entity  Type: 

Matrix 

Description: 

Stiffness  matrix  in  the  direct  set  used  in  frequency  response  analysis. 

Matrix  Form: 

Complex  square  matrix  with  the  number  of  rows  and  columns  equal  to  the  num¬ 
ber  of  degrees  of  freedom  in  the  d-set.Created  By: 

DMA 

Entity: 

KDDT 

Entity  Type: 

Matrix 

Description: 

Stiffness  matrix  in  the  direct  set  used  in  frequency  response  analysis. 

Matrix  Form: 

Complex  square  matrix  with  the  number  of  rows  and  columns  equal  to  the  num¬ 
ber  of  degrees  of  freedom  in  the  d-set.  Created  By: 

DMA 

Entity: 

KEE 

Entity  Type: 

Matrix 

Description: 

A  partition  of  the  GENK  matrix  that  contains  only  elastic  degrees  of  freedom. 
Used  in  the  nuclear  blast  response  analysis. 

Matrix  Form: 

Complex  square  matrix  with  the  number  of  rows  and  columns  equal  to  the  num¬ 
ber  of  elastic  modes  retained  for  the  blast  analysis. 

Created  By: 

MAPOL 
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Entity: 

Entity  Type: 
Description: 
Entity  Structure: 
Record: 


Created  By: 
Notes: 


KELM 

Unstructured 

Contains  the  element  stiffness  matrix  partitions. 


i.  If  the  element  is  a  scalar  element: 

the  record  contains  the  components  of  the  connected  grid  point(s)  (if 
any)  and  the  value  K. 


KCODE 

FORMAT  OF  RECORD 

1 

K 

2 

COMF1,  0,  +- K,  -+K 

3 

0,  COMP1,  +- K,  -+K 

4 

+-K,  -+K 

5 

COMP1,  0,  K 

6 

COMP1,  COMP2,  +-K,  -+K 

Else 

the  record  contains  a  partition  of  the  stiffness  matrix  with  either  1,  3, 
or  6  entries  for  each  node 


KCODE 

FORMAT  OF  RECORD 

7 

3  columns  of  3  entries/node 

8 

3  columns  of  3  entries/node 

9 

6  columns  of  6  entreis/node 

Module  EMG 

1.  This  entity  contains  one  record  for  each  strip  of  each  element  stiffness  matrix. 
A  strip  or  partition  is  defined  as  all  those  columns  of  the  element  matrix  asso¬ 
ciated  with  a  pivot  sil  (the  id  of  the  first  DOF  of  a  grid  point  or  the  id  of  a  sca¬ 
lar  point). 

2.  Refer  to  the  DVCT  relation  for  further  details,  as  these  two  data  base  entities 
are  closely  linked. 

3.  The  matrix  partitions  are  stored  in  the  same  precision  as  the  KGG  matrix. 


CH/I 

W  - 


Entity: 
Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


KEQE 

Matrix 

Structural  plus  aerodynamic  stiffness  matrix  for  the  elastic  modes  retained  in  the 
blast  response  analysis. 

Complex  square  matrix  with  the  number  of  rows  and  columns  equal  to  the  num¬ 
ber  of  elastic  modes  retained  for  the  blast  analysis. 

MAPOL 


1.  KEQE  is  obtained  from  [  KEQE  ]  =  [  K2E  ]  +  [  qee  ] 

KFF 

Matrix 

Partition  of  the  KNN  matrix  (see  KGG). 

KFS 

Matrix 

Partition  of  the  KNN  matrix  (see  KGG). 

KGG 

Matrix 

Contains  the  current  global  stiffness  matrix  for  the  design  problem. 

A  variable-size  symmetric  matrix  having  one  row  and  one  column  for  each  struc¬ 
tural  degree  of  freedom  in  the  problem. 

Module  MAPOL 


1.  The  KGG  matrix  is  formed  in  the  second  phase  stiffness  matrix  assembly. 

2.  The  MAPOL  sequence  supports  the  following  partitions  of  the  KGG  matrix 
(see  the  Theoretical  Manual  for  the  explicit  formation  of  these  submatrices): 


KGG  -> 

xm  -> 


9  i  9 

9 

KSS  |  9 

KFS  | KNN 


KFF 


KOO*  |  KOA* 
9  I KSA 


KAA 


9  I  9 

KLR  |  KLL 


*  Generalized  dynamic  reduction  only 
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Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


KHHF 

Subscripted  Matrix 

Stiffness  matrix  in  the  modal  set  vised  in  frequency  response  and  flutter  analyses. 

Complex  square  matrix  with  the  number  of  rows  and  columns  equal  to  the  num¬ 
ber  of  degrees  of  freedom  in  the  h-set. 

DMA 

1.  The  matrix  may  be  required  in  the  flutter  sensitivity  analysis  and  is  therefore 
subscripted  by  boundary  condition. 

KHHT 

Subscripted  Matrix 

Stiffness  matrix  in  the  moaal  set  used  in  transient  response  analysis. 

Complex  squ  ire  matrix  with  the  number  of  row3  and  columns  equal  to  the  num¬ 
ber  of  degrees  of  freedom  in  the  h-set. 

DMA 


KLL 


Matrix 

Partition  of  tb-  KAA  matrix  (see  KGG). 

KLL  1  MV 

Subscripted  Matrix 

Contains  the  upper  and  lower  triangular  sections  of  the  [KLL]  symmetric  stiff¬ 
ness  matrix. 

A  variable-::  xod  matrix  having  one  row  and  one  column  for  each  degree  of  free¬ 
dom  left  over  for  analysis  ,'fter  partifcion/reduction.  The  precision  of  this  matrix 
is  the  same  as  the  KGG  matrix. 

SDCOMP 

1.  This  matrix  is  formed  for  use  by  the  FBS  utility. 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 
Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Matrix  Form: 
Created  By: 
Notes- 


Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


IfLLL 

Matrix 

Contains  the  lower  triangular  portion  of  the  decomposed  KAAA  matrix.  Note 
that  KAAA  is  asymmetric  requiring  use  of  the  general  decomposition  routine. 

Refer  to  the  DECOMP  utility  documentation. 

DECOMP 

1.  This  matrix  is  formed  to  be  used  in  the  general  forward  backward  substitu¬ 
tion  module  GFBS. 

KLLU 

Matrix 

Contains  the  upper  triangular  portion  of  the  decomposed  partition  of  the  KAAA 
matrix.  Note  that  KAAA  is  asymmetric  requiring  use  of  the  general  decomposi¬ 
tion  routine. 

Refer  to  the  DECOMP  utility  documentation. 

DECOMP 

1.  This  matrix  is  formed  to  be  used  in  the  general  forward  backward  substitu¬ 
tion  module  GFBS. 

KLR 

Matrix 

A  partition  of  the  KAA  matrix  (see  KGG). 

KL11 

Subscripted  Matrix 

Lower  triangular  portion  of  the  decomposed  Kll  matrix. 

Square  real  matrix  having  one  row  and  one  column  for  each  a-set  degree  of  free¬ 
dom. 

DECOMP 

1.  Kll  is  not  symmetric. 

2.  This  matrix  is  formed  for  use  by  the  GFBS  utility. 

3.  The  matrix  may  be  required  in  the  sensitivity  analysis  and  is  therefore  sub¬ 
scripted  by  boundary  condition. 
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Entity: 
Entity  Type: 
Description: 

Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 
Created  By: 
Notes: 


Entity: 

Entity  Type' 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


KNN 

Matrix 

A  partition  of  the  KGG  matrix  (see  KGG). 

KOA 

Matrix 

A  partition  of  the  KFF  matrix  used  in  Generalized  Dynamic  reduction. 

Real  rectangular  matrix  with  one  row  for  each  o-set  degree  of  freedom  and  one 
column  for  each  a-set  degree  of  freedom. 

PARTN 

1.  This  matrix  is  required  only  for  generalized  dynamic  reduction  and  only 
when  the  user  has  specified  a-set  degrees  of  freedom. 

KOO 

Matrix 

A  partition  of  the  KFF  matrix  used  in  Generalized  Dynamic  reduction. 

Real  squar  matrix  with  one  row  for  each  o-set  degree  of  freedom. 

PARTN 

1.  This  matrix  is  required  only  for  generalized  dynamic  reduction. 

2. 

If  the  user  has  not  specified  a-set  degrees  of  freedom,  KOO  is  equivalented  to 
KFF. 

KOOINV 

Subscripted  Matrix 

Contains  the  upper  and  lower  triangular  matrices  resulting  from  the  symmetric 
decomposition  of  the  KOO  matrix  for  the  current  boundary  condition. 

A  variable-sized  matrix  having  one  row  and  one  column  for  each  omitted  degree 
of  freedom  in  the  boundary  condition. 

FREDUCE 

1.  This  matrix  has  the  same  precision  as  the  global  stiffness  matrix. 

2.  If  no  degrees  of  freedom  have  been  omitted  in  the  current  boundary  condition, 
this  matrix  will  have  no  rows  or  columns. 

3.  This  matrix  is  formed  for  use  by  the  Forward  Backward  Substitution  Utility. 

4.  Not..-  that  KOOINV  plays  the  same  role  as  KOOL/KOOU  for  symmetric  analy¬ 
ses. 
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Entity: 

KOOL 

Entity  Type: 

Subscripted  Matrix 

Description: 

Contains  the  lower  triangular  portion  of  the  decomposed  partition  of  the  KAAA 
matrix.  Note  that  KAAA  is  asymmetric  requiring  use  of  the  general  decomposi¬ 
tion  routine. 

Matrix  Form: 

Refer  to  the  DECOMP  utility  documentation. 

Created  By: 

FREDUCE 

Notes: 

1.  This  matrix  is  formed  to  be  used  in  the  general  forward  backward  substitu¬ 
tion  module  GFBS. 

2.  Note  that  KOOL/KOOU  play  the  same  role  as  KOOINV  for  asymmetric  analy¬ 
ses. 

Entity: 

KOOU 

Entity  Type: 

Subscripted  Matrix 

Description: 

Contains  the  upper  triangular  portion  of  the  decomposed  partition  of  the  KAAA 
matrix.  Note  that  KAAA  is  asymmetric  requiring  use  of  the  general  decomposi¬ 
tion  routine. 

Matrix  Form: 

Refer  to  the  DECOMP  utility  documentation. 

Created  By: 

Module  DECOMP 

Notes: 

1.  This  matrix  is  formed  to  be  used  in  the  general  forward  backward  substitu¬ 
tion  module  GFBS. 

2.  Note  that  KOOL/KOOU  play  the  same  role  as  KOOINV  for  asymmetric  analy¬ 
ses. 

Entity: 

KSQO 

Entity  Type: 

Matrix 

Description: 

•Shifted  stiffness  matrix  used  in  Generalized  Dynamic  reduction. 

Matrix  Form: 

Real  square  symmetric  matrix  with  one  row  and  one  column  for  each  o-set  of  de¬ 
gree  of  freedom. 

Created  By: 

Module  GDR1 

Notes: 

1.  This  matrix  is  computed  from:  [  KSOO  ]  =  [  KOO  ]  -  (s )  [  MOO]; 
with  the  sniff  parameter,  s,  computed  in  GRD1. 

Entity: 

KSS 

Entity  Type: 

Matrix 

Description: 

Partition  of  the  KNN  matrix  (see  KGG). 
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Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 

Matrix  Form: 


KU11 

Subscripted  Matrix 

Upper  triangular  portion  of  the  decomposed  KU  matrix. 

Square  real  matrix  having  one  row  and  one  column  for  each  a-set  degree  of  free¬ 
dom. 

DECOMP 

1.  Kll  is  not  symmetric. 

2.  This  matrix  is  formed  for  use  by  the  GFBS  utility. 

3.  The  matrix  may  be  required  in  the  sensitivity  analysis  and  is  therefore  sub¬ 
scripted  by  boundary  condition. 

Kll 

Matrix 

An  intermediate  matrix  that  is  constructed  as  part  of  the  solution  of  unrestrained 
structures. 

Areal,  square  matrix  with  the  number  of  rows  and  columns  equal  to  the  number 
of  a-set  degrees  of  freedom.Created  By: 

MAPOL 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


K1112 

Subscripted  Matrix 

An  intermediate  matrix  required  in  the  static  aeroelastic  trim  analysis. 

Areal  rectangular  matrix  with  the  number  of  rows  equal  to  the  number  of  a-set 
degrees  of  freedom  and  the  number  of  columns  equal  to  the  number  of  r-set  de¬ 
grees  of  freedom. 

MAPOL 

1.  The  K1112  matrix  is  computed  as  the  solution  of 

[  Kll  ]  *  [  K1112  ]  =  [  £X CS  ] 

2.  The  matrix  may  be  required  in  the  sensitivity  analysis  and  is  therefore  sub¬ 
scripted  by  boundary  condition. 
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Entity: 
Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


K12 

Subscripted  Matrix 

An  intermediate  matrix  that  is  constructed  as  part  of  the  solution  of  unrestrained 
structures. 

A  real  rectangular  matrix  with  the  number  of  rows  equal  to  the  number  of  a-set 
degrees  of  freedom  and  the  number  of  columns  equal  to  the  number  of  v-set  de¬ 
grees  of  freedom. 

MAPOL 

1.  The  matrix  ?nay  be  required  in  the  sensitivity  analysis  and  is  therefore  sub¬ 
scripted  by  boundary  condition. 

K21 

Subscripted  Matrix 

An  intermediate  matrix  used  in  the  reduction  of  the  aerodynamic  stiffness. 

The  number  of  rows  is  equal  to  the  number  of  degrees  of  freedom  in  the  r-eefc  and 
the  number  of  columns  is  equal  to  the  number  of  rows  in  the  a-oot. 

MAPOL 

1.  The  matrix  is  created  from  the  column  merge  of  R32  and  R31. 

2.  Since  this  matrix  is  required  in  the  sensitivity  analysis,  it  is  subscripted  by 
the  boundary  condition  number. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


LAMBDA 

Relation 

Contains  the  results  of  real  eigenvalue  analysis  for  each  modal  analysis  in  each 
boundary  condition. 


NAME 

TYPE/KEY 

DESCRIPTION 

NITER 

Integer 

Iteration  number 

BCID 

Integer 

The  boundary  condition  number 

KODENO 

Integer 

The  mode  number  of  the 
eiganvalue/eigenvoctor 

EXORD 

Integer 

The  extraction  order  for  the  mode 

EIGVAL 

Real 

The  eigenvalue 

RFREQ 

Real 

The  modal  frequency  in  rad/s 

CFREQ 

Real 

The  modal  frequency  in  Hertz 

VECFLG 

Integer 

=  1  if  a  vector  was  generated  for  the  mode 
=  0  if  only  the  value  was  extracted 

GMASS 

Real 

The  generalized  mass  associated  with  the 
mode 

GSTIFF 

Real 

The  generalized  stiffness  associated  with 
the  mode 

Module  REIG 


1.  The  relation  contains  one  tuple  for  each  mode  extracted  in  each  eigenanalysis. 

2.  All  eigenvalues  for  ail  boundary  conditions  at  each  design  iteration  are  stored 
for  retrieval  in  sensitivity  evaluation. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


LAMDAC 

Relation 

Contains  the  results  of  complex  eigenvalue  analysis  for  each  modal  analysis  in 
each  boundary  condition. 


NAME 

TYPE/KEY 

DESCRIPTION 

BCID 

Integer 

The  boundary  condition  number 

MODENO 

Integer 

The  mode  number  of  the 
eigenvalue/eigenvector 

EXORD 

Integer 

The  extraction  order  for  the  mode 

REIGVAL 

Real 

The  real  part  of  the  eigenvalue 

IEIGVAL 

Real 

The  imaginary  part  of  the  eigenvalue 

NFREQ 

Real 

The  natural  frequency  in  Hertz 

DFREQ 

Real 

The  damped  frequency  in  Hertz 

DPCOEF 

Real 

The  damping  coefficient 

Module  CEIG 

1.  The  relation  contains  one  tuple  for  each  mode  extracted  in  each  eigenanalysis. 

LDVLIST 

Relation 

Contains  the  definition  of  the  list  of  local  design  iterations  as  input  from  the  Bulk 
Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer 

Set  identification  number 

ETYPE 

Tbxt(8) 

Element  type 

LAYRNUM 

Integer 

Layer  number  for  composites  or  zero 

EID 

Integer 

Element  identification  number 

Module  IFP 
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Entity: 
Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


LHS 

Subscripted  Matrix 

This  is  essentially  a  matrix  of  rigid  body  mass  values  with  the  exact  definition  de¬ 
pending  on  the  type  of  free-free  analysis  being  performed. 

The  dimension  of  the  square  matrix  is  equal  to  the  number  of  degrees  of  freedom 
in  the  r-set. 

MAPOL 

1.  For  an  inertia  relief  analysis,  LHS  is  equal  to  MRR. 

2.  For  a  static  aeroelastic  analysis,  LHS  is  equal  to  MRR  plus  K21  times  K1112. 

LKQ 

Matrix 

Lower  triangular  portion  of  the  decomposed  KEQE  matrix. 

Square  real  matrix  having  one  row  and  one  column  for  each  elastic  mode  retained 
in  the  nuclear  blast  response  analysis. 

DECOMP 

1.  KEQE  is  not  symmetric. 

2.  This  matrix  is  formed  for  use  by  the  GFBS  utility. 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


LOAD 

Relation 

Contains  the  definition  of  a  static  load  that  is  a  linear  combination  of  loads  de¬ 
fined  by  FORCE,  MOMENT,  FORCE1,  MOMENT1,  PLOAD,  and  GRAY  entries. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

SCALE 

Real 

Scale  factor  for  combination 

SCALE I 

Real 

Scale  factor  for  component  load 

LOADI 

Integer  >  0 

Set  identification  number  of  the  component 
load 

Created  By: 
Notes: 


Module  IFP 

1.  The  relation  contains  one  tuple  for  each  load  set  id  specified  in  each  unique 
SETID. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 


LOCLVAR 

Relation 

Contains  the  relationship  between  local  variables  and  global  variables  in  the  de¬ 
sign  problem.  Acts  as  a  pointer  to  the  PTRANS  matrix. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification 

ETYPE1 

Tfext  (8) 

Element  type 

LAYRNUM 

Integer  >  0 

Layer  number  for  composites 

PROW 

Integer  >  0 

Pointer  to  (P)  row  for  this  element 

PTYP 

Integer  =  1,  2  or  3 

Flag  indicating  type  of  associated  global 
variable 

TMIN 

Real 

Minimum  value  for  physical  property 

TMAX 

Real 

Maximum  value  for  physical  property 

Module  MAKEST 

1.  This  entity  is  used  to  create  move  limits  on  the  physical  design  variables  in 
the  TCEVAL  module. 

2.  The  PTYP  attribute  indicates  the  linking  option  for  the  physical  variable 
=  1  unique  physical  linking  (DESELM) 

=  2  physical  linking  (DESVARP) 

=  3  shape  function  linking  (DESVARS) 

LSOO 

Matrix 

Lower  triangular  portion  of  the  decomposed  KSOO  matrix. 

Square  real  matrix  having  one  row  and  column  for  each  o-set  degree  of  freedom 
in  Generalized  Dynamic  Reduction. 

DECOMP 

1.  This  matrix  is  formed  for  use  by  the  FBS  large  matrix  utility. 

2.  LSOO  is  computed  only  when  there  are  k-set  degrees  of  freedom  in  a  general¬ 
ized  dynamic  reduction  analysis. 

MAA 

Matrix 

Mass  matrix  in  the  a-set  derived  from  partitions  of  the  MFF  matrix  (see  MGG). 
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Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 


MAABAR 

Matrix 

A  partition  of  the  MFF  matrix  (see  MGG). 

MASSE ST 
Relation 

Contains  the  element  summary  data  for  the  MASS1  and  MASS2  elements. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

SIL1 

Integer  £  0 

Internal  grid  or  scalar  point  id 

SIL2 

Integer  >  0 

Internal  grid  or  scalar  point  id 

COMPNT1 

Integer  >  0 

Component  of  SIL1  to  which  the  element  is 
attached 

COMPNT2 

Integers  0 

Component  of  SIL2  to  which  the  element  is 
attached 

MASS 

Real 

Mass  value 

DESIGN 

Integer  >  0 

Design  flag 

Module  MAKEST 


1.  A  nonzero  design  flag  denotes  that  the  element  is  affected  by  a  design  vari¬ 
able. 

2.  This  relation  is  built  from  the  CMASS1  and  CMASS2  relations  along  with  as¬ 
sociated  property,  design  and  grid  relations.  It  contains  one  tuple  for  each 
scalar  mass  element  in  the  problem. 

MATSS 

Matrix 

Matrix  of  steady-state  influence  coefficients  used  in  the  nuclear  blast  response 
analysis. 

Real  square  matrix  with  one  row  and  column  for  each  panel  in  the  unsteady  aero¬ 
dynamics  model. 

Module  BLASTFIT 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


MATTR 

Matrix 

Matrix  of  transient  influence  coefficients  used  in  the  nuclear  blast  response  analy¬ 
sis. 

Real  rectangular  matrix  with  one  row  for  each  panel  in  the  unsteady  aerodynam¬ 
ics  model  and  a  column  dimension  equal  to  the  number  of  panels  times  the  num¬ 
ber  of  beta  values  used  in  fitting  procedure  of  the  transient  blast  response 
calculations. 

Module  BLASTFIT 

MAT1 

Relation 

Contains  the  material  properties  for  linear  isGtropic  materials  as  input  from  the 
Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

HID 

Integer  >  0,  key 

Material  property  identification 

E 

Real 

Young’s  Modulus 

G 

Real 

Shear  Modulus 

NU 

Real 

Poisson’s  Ratio 

RHO 

Real 

Density 

ALPHA 

Real 

Thermal  expansion  coefficient 

TREF 

Real 

Thermal  expansion  reference  temperature 

DAMPING 

Real 

Structural  damping  coefficient 

ST 

Real 

Tension  stress  allowable 

SC 

Real 

Compression  stress  allowable 

SS 

Real 

Shear  stress  allowable 

MSCLlD 

Integer  >  0 

Material  coordinate  system  id 

Created  By: 


Module  IFF 


MAT2 

Relation 

Contains  the  material  properties  for  linear  anisotropic  materials  for  two  dimen¬ 
sional  e’ements  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

MID 

Integer  >  0,  key 

Material  identification  number 

Gil,  G12,  G13 

Real 

Components  of  the  6x6  symettric 
material  properties  matrix 

G22 ,  G23,  G33 

Real 

RHO 

Real 

Density 

ALPH1 

Real 

Thermal  expansion  coefficient  vector 

ALPH2 

Real 

ALPH12 

Real 

TREF 

Real 

Thermal  expansion  reference 
temperature 

DAMPING 

Real 

Structural  damping  coefficient 

ST 

Real 

Tension  stress  allowable 

SC 

Real 

Compression  stress  allowable 

SS 

Real 

Shear  stress  allowable 

MSCID 

Integer  >  0 

Material  coordinate  system  id 

Created  By:  Module  IFF 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


MAT  8 
Relation 

Contains  the  material  properties  for  orthotropic  materials  for  two-dimensional 
elements  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

MID 

Integer  >  0,  key 

Material  identification  number 

El 

Real  *  0.0 

Logitudinal  modulus  of  elasticity 

E2 

Real  i4  0.0 

Transverse  modulus  of  elasticity 

NU12 

Real 

Poisson’s  ratio 

G12 

Real  >  0.0 

In-plane  shear  modulus 

G1Z 

Real  £  0.0 

Transverse  shear  modulus  in  1-z  plane 

G2Z 

Real  £  0.0 

Transverse  shear  modulus  in  2-z  plane 

RHO 

Real  £  0.0 

Mass  density 

ALPH1 

Real 

Thermal  expansion  coefficient  in  1-direction 

ALPH2 

Real 

Thermal  expansion  coefficient  in  2-direction 

TREF 

Real 

Element  reference  temperature 

XT 

Real  £  0.0 

Allowable  longitudinal  tension  stress 

XC 

Real 

Allowable  longitudinal  compression  stress 

YT 

Real  >  0.0 

Allowable  transverse  tension  stress 

YC 

Real 

Allowable  transverse  compression  stress 

SS 

Real  £  0.0 

Allowable  in-plane  shear  stress 

DAMPING 

Real 

Ptp’itufu!  dammoc  value 

F12 

*7^ 

iW  W-  .  tfcttso*  vh/nr/i  ‘  -v.I  theory 
interaction  te  \n 

Module  IFF 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


MAT  9 
Relation 

Contains  the  material  properties  for  orthotropic  materials  for  three-dimensional 
elements  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

MID 

Integer  >  0,  key 

Material  identification  number 

Gil 

Real 

Tfensile  modulus  in  the  1-direction 

G12 

Real 

Shear  modulus  in  the  1-2  plane 

G13 

Real 

Shear  modulus  in  the  1-3  plane 

G14 

Real 

Shear  modulus  in  the  1-4  plane 

G15 

Real 

Shear  modulus  in  the  1-5  plane 

G16 

Real 

Shear  modulus  in  the  1-6  plane 

G22 

Real 

Tensile  modulus  in  the  2-direction 

G23 

Real 

Shear  modulus  in  the  2-3  plane 

G24 

Real 

Shear  modulus  in  the  2-4  plane 

G25 

Real 

Shear  modulus  in  the  2-5  plane 

G26 

Real 

Shear  modulus  in  the  2-6  plane 

G33 

Real 

Tfensile  modulus  in  the  3-direction 

G34 

Real 

Shear  modulus  in  the  3-4  plane 

G35 

Real 

Shear  modulus  in  the  3-5  plane 

G36 

Real 

Shear  modulus  in  the  3-6  plane 

G44 

Real 

Tfensile  modulus  in  the  4-direction 

G45 

Real 

Shear  modulus  in  the  4-5  plane 

G46 

Real 

Shear  modulus  in  the  4-6  plane 

G55 

Real 

Tfensile  modulus  in  the  5-direction 

G56 

Real 

Shear  modulus  in  the  5-6  plane 

G66 

Real 

Tfensile  modulus  in  the  6-direction 

RHO 

Real 

Mass  Density 

ALPH1 

Real 

Thermal  expansion  coefficient  in  1-direction 

ALPH2 

Real 

Thermal  expansion  coefficient  in  2-direction 

ALPH3 

Real 

Thermal  expansion  coefficient  in  3-direction 

ALPH4 

Real 

Thermal  expansion  coefficient  in  4-direction 

ALPHS 

Real 

Thermal  expansion  coefficient  in  5-direction 
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j  NAME 

TYPE/KEY 

DESCRIPTION 

ALPH6 

Real 

Thermal  expansion  coefficient  in  6-direction 

THSr 

Real 

Element  reference  temperature 

|  GE 

Real 

Structural  damping  coefficient 

Created  By: 

Module  lb? 

Entity: 

MDD 

Entity  Type: 

Matrix 

Description- 

Mass  matrix  in  the  direct  set. 

Matrix  Form: 

Square  matrix  with  the  number  of  rows  and  columns  equal  to  the  number  of  de¬ 
grees  of  freedom  in  the  d-  set. 

Created  By: 

DMA. 
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Entity: 

Entity  Type: 
Description: 

Entity  Structure: 
Record: 


Created  By: 
Notes: 


ME  12*1 

Unstructured 

An  unstructured  database  entity  that  contains  the  element  mass  matrix  parti¬ 
tions. 


i.  If  the  element  is  a  scalar  element: 

the  record  contains  the  components  of  the  connected  grid  point(s)  (if 
any)  and  the  value  M. 


MCODE 

FORMAT  OF  RECORD 

1 

M 

2 

COMF1,  0,  +-M.-+M 

3 

0, COMF1,  +-M.-+M 

4 

+-M,— hM 

5 

COMP1,  0,  M 

6 

COMP1,  COMP2,  +-M.-+M 

Else 

the  record  contains  a  partition  of  the  stiffness  matrix  with  either  one, 
three,  or  six  entries  for  each  node 


KCODE 

FORMAT  OF  RECORD 

7 

3  columns  of  3  entries/node 

10 

3  columns  of  1  entry/node  (diagonal) 

Module  EMG 

1.  This  entity  contains  one  record  for  each  strip  of  each  element  mass  matrix.  A 
strip  or  partition  is  defined  as  all  those  columns  of  the  element  matrix  associ¬ 
ated  with  a  pivot  sil  (the  id  of  the  first  dof  of  a  grid  point  or  the  id  of  a  scalar 
point). 

2.  Refer  to  the  DVCT  relation  for  further  details,  as  these  two  database  entities 
are  closely  linked. 

3.  The  matrix  partitions  are  stored  in  the  same  precision  as  the  MGG  matrix. 
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Entity: 
Entity  "type: 
Description: 


MFF 

Matrix 

A  partition  of  the  MNN  matrix  (see  MGG). 


Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


MFORM 

Relation 

Contains  the  mass  matrix  form  as  specified  in  the  Bulk  Data  file. 


NAMES 

TYPE/KEY 

DESCRIPTION 

VALUE 

Ttext  (3) 

The  mass  matrix  form;  either  LUMPED  or 
COUPLED. 

Notes: 


1.  If  this  relation  is  empty,  the  LUMPED  form  will  be  used.  If  more  than  one  tu¬ 
ple  is  defined,  any  tuple  cont  aining  the  "COUPLED"  option  will  cause  the  cou¬ 
pled  mass  form  to  be  used. 


Entity: 
Entity  Type: 
Description: 
Matrix  Form 

Created  By: 
Notes: 


MGG 

Matrix 

Contains  the  current  global  mass  matrix  for  the  design  problem. 

A  w.riable-size  symmetric  (possibly  diagonal)  matrix  having  one  row  and  one  col¬ 
umn  for  each  structural  degree  of  freedom  in  the  problem. 

Module  MAPOL 

1.  The  MGG  matrix  is  formed  in  the  second  phase  mass  matrix  assembly. 

2.  The  MAPOL  cequence  supports  the  following  partitions  of  the  MGG  matrix 
(see  Theoretical  Manual  for  the  explicit  formation  of  these  matrices): 

9  1  9  1 

q>  IMNN  J 

9  1  9  ] 

q>  |  MFF 

MOO  I  MPA 
9  j  MAPBJAR 

MBJRSAR  |  9 

MLR  j  MLL 


MGG  — f 

Mm  -> 

MST 

M&a 
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Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


MHH 

Subscripted  Matrix 

Contains  the  modal  mass  output  from  the  dynamic  matrix  assembly. 

A  variable-sized  matrix  having  one  row  and  one  column  for  each  eigenvector  com¬ 
puted  in  the  real  eigenanalysis. 

Module  DMA 

1.  This  matrix  is  needed  for  flutter  constraint  sensitivities  so  it  is  subscripted 
for  each  boundary  condition. 

2.  INFO(ll)  contains  a  flag  denoting  whether  the  matrix  is  coupled  or  uncoupled 

=  0  Uncoupled 

=  1  Coupled 


Mil 

Matrix 

Generalized  mass  matrix  computed  by  the  eigenanalysis  module. 

Square  diagonal  matrix  with  the  number  of  rows  and  columns  equal  to  the  num 
ber  of  modes  retained  by  the  eigenanalysis. 

Module  REIG 

1.  Currently,  this  matrix  is  computed  and  not  used;  it  is  available  for  printout. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


MKAEROl 

Relation 

Contains  a  table  of  Mach  numbers  and  reduced  frequencies  for  unsteady  aerody¬ 
namic  matrix  calculation  as  input  from  the  bulk  data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SYMXZ 

Integer 

Symmetry  flag  for  xz-plane 

SYMXY 

Integer 

Symmetry  flag  for  xy-plane 

MACH1 

Real 

Mach  number 

MACH2 

Real 

MACH3 

Real 

MACH4 

Real 

MACH5 

Real 

MACH6 

Real 

RFREQ1 

Real 

Reduced  frequencies 

RFREQ2 

Real 

RFREQ3 

Real 

RFREQ4 

Real 

RFREQ5 

Real 

RFREQ6 

Real 

RFREQ7 

Real 

RFREQ8 

Real 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 
Entity  Type: 
Description: 

Entity: 
Entity  Type: 
Description: 

Entity: 
Entity  Type: 
Description: 

Entity: 
Entity  Type: 
Description: 


MKAER02 

Relation 

Contains  mach  number  and  reduced  frequency  pairs  to  be  used  in  unsteady  aero¬ 
dynamic  matrix  generation. 


NAME 

TYPE/KEY 

DESCRIPTION 

SYMXZ 

Integer 

Symmetry  flag  for  xz-plane 

SYMXY 

Integer 

Symmetry  flag  for  xy-plane 

MACH 

Real  >  0.0 

Mach  number 

RFREQ 

Real  >  0.0 

Reduced  frequency 

Module  IFP 

MLL 

Matrix 

A  partition  of  the  MAA  matrix  (see  MGG). 

MLR 

Matrix 

A  partition  of  the  MAA  matrix  (see  MGG). 

MNN 

Matrix 

The  mass  matrix  in  the  n-set  derived  from  Dartition  of  the  MGG  matrix  (see 
MGG). 


MOA 

Matrix 

A  partition  of  the  MFF  matrix  (see  MGG). 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


MODE LI ST 
Relation 

Contains  the  list  of  normal  modes  for  which  outputs  are  requested  as  input  from 
the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer 

Set  identification  number 

MODE 

Integer 

Mode  number 

module  IFP 


MOMENT 

Relation 

Contains  the  definition  of  a  static  moment  at  a  grid  point  as  input  from  the  Bulk 
Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

GRID1 

Integer  >  0 

Grid  point  at  which  the  moment  is  applied 

CID1 

Integer  >  0 

Coordinate  system  identification 

SCALE 

Real 

Scale  factor 

Nl,  N2,  N3 

Real 

Components  of  the  vector 

Module  IFP 


587 


Entity: 
Entity  Type: 
Description: 


MOMENT1 

Relation 


Contains  the  definition  of  a  moment  applied  at  a  grid  point  with  the  direction  de¬ 
termined  by  a  line  connecting  two  grid  points. 

Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

GRID1 

Integer  >  0 

Grid  point  id  at  which  the  moment  is  applied 

SCALE 

Real 

Scale  factor 

GRID2 

Integer  >  0 

Grid  point  identification 

GRID3 

Integer  >  0 

Grid  point  identification 

Created  By: 

Module  IFP 

Entity: 

MOO 

Entity  Type: 

Matrix 

Description: 

A  partition  of  the  MFF  matrix  (see  MGG). 

Entity: 

MPART 

Entity  Type: 

Matrix 

Description: 

A  partitioning  vector  used  to  separate  rigid  body  and  elastic  modes  for  nuclear 
blast  response. 

Matrix  Form: 

Areal  vector  with  the  number  of  rows  equal  to  the  number  of  modes  retained  for 
the  nuclear  blast  response.  Rigid  modes  are  denoted  by  0.0  while  elastic  modes 
are  denoted  by  1.0. 

Created  By: 

Module  BLASTFIT 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


MPC 

Relation 

Contains  the  multipoint  constraint  data  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

DEPEND 

Integer  >  0 

Dependent  grid  or  scalar  point  id 

COMPNT1 

Integer  >  0 

Component  of  DEPEND  that  is  constrained 

DEPCOEF 

Real 

Coefficient  of  constraint  for  the  dependent  dof 

GRID2 

Integer  >  0 

Grid  or  scalar  point  id 

COMPNT2 

Integer  >  0 

Component  of  GRED1  that  specifies  a  constraint 

MPCCOEF 

Real 

Coefficient  of  constraint 

Module  IFP 


1.  The  relation  contains  one  tuple  for  each  component  constrained  in  each 
unique  SETID. 

MPCADD 

Relation 

Contains  the  definition  of  a  multipoint  constraint  set  that  is  a  union  of  sets  con¬ 
tained  in  the  MPC  relation. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

MPCSETID 

Integer  >  0 

The  SETID  of  the  MPC  relation  tuples  to  be 
used 

Module  IFP 
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Entity: 
Entity  Type: 
Description: 


Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 


MPPARM 

Realtion 

Contains  the  optimizer  parameters  and  their  new  values  for  use  in  the  ASTROS 
mathematical  programming  optimizer  as  input  from  the  Bulk  Data  File. 


NAME 

TYPE/KEY 

DESCRIPTION 

PARAM 

Tfext  (8) 

Name  of  the  parameter 

INTPARM 

Integer 

Value  of  integer  parameters 

RSPPARM 

Real 

Value  of  real  parameters 

Module  IFP 

1.  This  relation  is  used  in  module  DESIGN  to  provide  for  user  specification  of 
optimizer  parameters. 

MRR 

Subscripted  Matrix 

Tb  reduce  mass  matrix  for  the  structural  model. 

A  variable-sized  matrix  having  one  row  and  one  column  for  each  degree  of  free¬ 
dom  in  the  support  set  for  the  current  boundary  condition. 

MAPOL 

1.  This  matrix  is  required  to  compute  strength  constraint  sensitivities  for  unre¬ 
strained  structures  and  trim  parameter  sensitivities  for  steady  aerolastic  opti¬ 
mization  so  it  is  subscripted  for  each  boundary  condition. 

MRRBAR 

Matrix 

A  partition  of  the  MAA  matrix  (see  MGG). 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


OAGRDDSP 

Relation 

Contains  the  displacements  on  the  aerodynamic  boxes  (“grids”)  for  static  aeroelas- 
ticity,  flutter,  transient/gust  and  blast  disciplines  that  are  requested  for  print  or 
punch  in  Solution  Control. 


NAME 

TYPE/KEY 

DESCRIPTION 

NITER 

Integer 

Iteration  number 

BCID 

Integer 

The  boundary  condition  number 

DISC 

Integer 

Discipline  type  flag  from  CASE 

SUBCASE 

Integer 

Subcase  identification  number  from  CASE 
relation 

MODENO 

Integer 

Normal  mode  number  for  FLUTTER 

CMPLX 

Integer 

Real  or  complex  flag 
=  1  if  real  displacement 
=  2  if  complex  displacement 

EXT  ID 

Integer 

External  identification  number  of  the 
aerodynamic  box  (See  Remark  1) 

INTID 

Integer 

Internal  identification  number  of  the 
aerodynamic  box 

RDISP 

Real 

Real  part  of  the  normal  displacement 

IDISP 

Real 

Imaginary  part  of  the  normal  displacement 

Many  Modules 

1.  The  “grids”  referred  to  by  the  EXTED  are  actually  the  aerodynamic  box  ele¬ 
ments.  Each  of  these  elements  is  physically  located  at  the  centroid  of  a  quadri¬ 
lateral  or  triangular  plate  (the  location  of  which  is  stored  in  GEOMSA  or 
GEOMUA  depending  on  the  model). 

2,  The  DISC  flag  also  indicates  which  model  is  referred  to  by  the  results: 

SAERO  refers  to  the  planar  static  aero  model 

FLUTTER,  'TRANSIENT,  FREQUENCY  and  BLAST  refer  to  the  unsteady 
aero  model 
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Entity: 

Entity  Type: 
Description: 

Relation  Attribute?: 


Created  By: 
Notes: 


OAGRDLOD 

Relation 

Contains  the  trimmed  applied  steady  aerodynamic  forcer,  and  pressures  on  the 
planar  and  nonplanar  static  aerodynamic  boxes  (“grids”,'  that  are  requested  for 
print  or  punch  in  Solution  Control. 


NAME 

TYPE/KEY 

DESCRIPTION 

NITER 

Integer 

Iteration  number 

BCID 

Integer 

The  boundary  condition  number 

DISC 

Integer 

Discipline  type  flag  from  CASE 

SUBCASE 

Integer 

Subcase  identification  number  (Normal 
mode  number  for  FLUTTER) 

LOADTYPE 

'lfext(G) 

Label  identifying  the  type  of  the  load  (See 
Remark  1) 

EXT  ID 

Integer 

External  identification  number  of  the 
aerodynamic  box  (See  Remark  2) 

INTID 

Integer 

Internal  identification  number  of  the 
aerodynamic  box 

AREA 

Real 

Area  of  the  box 

FORCE 

Real 

Real  part  of  the  applied  normal  force 

PRESS 

Real 

Real  part  of  the  applied  pressure 

Many  Modules 

1.  The  LOADTYPE  is  a  textual  key  that  identifies  the  load  terms. 

The  following  values  are  used: 

APPLIED  -  User  defined  applied  load  from  all  disciplines  except 

NPSAERO.  For  NPSAERO,  the  APPLIED  load  is  equivalent 
to  the  RIGID  load.  The  RIGID  load  is  not  stored. 

RIGID  -  Trimmed  rigid  aerodynamic  load  from  SAERO 
FLEXIBLE  -  Trimmed  flexible  contribution  to  aerodynamic  load  from 
SAERO 

2.  The  “grids”  referred  to  by  the  SXTID  are  actually  the  aerodynamic  box  ele¬ 
ments.  Each  of  these  elements  is  phj  sically  located  at  the  centroid  of  a  quadri¬ 
lateral  or  triangular  plate  (the  location  of  which  is  stored  in  GEOMSA  or 
GEOMUA  depending  on  the  model). 

3.  The  DISC  flag  also  indicates  which  model  is  referred  to  by  the  results: 
NPSAERO  refers  to  the  nonplanar  static  aero  model 

SAERO  refers  to  the  planar  static  aero  model 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 

Entity: 
Entity  Type: 
Description: 


Created  By: 
Notes: 


OCEIGiJ 

Relation 

Contains  statistical  information  oi'&jrr  ■>W,x  -'ig*  /wall-  h  alysis. 


NAME 

TYPE/KEY 

DESCRIPTION 

METHOD 

Ttext(8) 

Method  of  complex  eigenvalue  extraction 

BCID 

Integer 

Boundary  condition  number 

NLAMA 

Integer 

Number  of  eigenvalue 

NVECTOR 

Integer 

number  of  eigenvectors 

NOSTRT 

Integer 

Number  of  passes  through  the  starting 
points 

NOMOVS 

Integer 

Number  of  starting  point  moves 

NODCMP 

Integer 

Number  of  decomposition 

ITER 

Integer 

Tbtal  number  of  iterations 

ITERM 

Integer 

Reason  for  termination 

Module  CEIG 

OCPARM 

Realtion 

Contains  the  optimizer  parameters  and  their  new  values  for  use  in  the  ASTROS 
optimality  criterion  methods  as  input  from  the  Bulk  Data  File. 


NAME 

TYPE/KEY 

DESCRIPTION 

PARAM 

Text  (8) 

Name  of  the  parameter 

INTPARM 

Integer  <  value  of  integer  parameters 

RSPPARM 

Real 

Value  of  real  parameters 

Module  EFP 

1.  Used  by  the  VANGO  module  to  override  default  values  of  control  parameters. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 


OEIGS 

Relation 

Contains  statistical  information  of  real  eigenvalue  analysis. 


NAME 

TYPE/KEY 

DESCRIPTION 

METHOD 

Ttext(8) 

Method  of  real  eigenvalue  extraction 

NITER 

Integer 

Design  iteration  number 

BCID 

Integer 

Boundary  condition  number 

MLAMA 

Integer 

Number  of  eigenvalue 

NVECTOR 

Integer 

number  of  eigenvectors 

NEVER 

Integer 

Number  of  eigenvalue  errors 

NVER 

integer 

Number  of  eigenvector  errors 

NOSTRT 

Integer 

Number  of  passes  through  the  starting 
points 

NOMOVS 

Integer 

Number  of  starting  point  moves 

NODCMP 

Integer 

Number  of  decomposition 

ITER 

Integer 

Tbtal  number  of  iterations 

ITERM 

Integer 

Reason  for  termination 

XMAX1 

Real 

Maximum  off  diagonal  mass  term 

I STORE 

Integer 

The  row  number  at  which  the  maximum  off 
diagonal  mass  term  is  located 

JSTORE 

Integer 

The  column  number  at  which  the 
maximum  off  diagonal  mass  term  is  located 

IMSG 

Integer 

Number  of  off  diagonal  mass  terms 

TITLE 

Text(72) 

Not  used 

SUBTITLE 

T3xt(72) 

LABEL 

Tfextm) 

Module  REIG 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 


OGPWG 

Relation 

Contains  data  from  the  pad  point  weight  generation  computations. 


NAME 

TYPE/KEY 

DESCRIPTION 

NITER 

Integer 

Iteration  number 

BCID 

Integer 

Boundary  condition  number 

GREF 

Integer 

Grid  point  identification  (or  zero) 

XO 

Real 

Basic  coordinates  of  the  reference  point 

YO 

Real 

ZO 

Real 

MO 

R  Vector(36) 

Mass  matrix  at  the  reference  point 

S 

R  Yector(9) 

Principal  axes  relative  to  basic  system 

MX 

Real 

Mass  in  the  x-axis  direction 

RX 

R  Vector(3) 

x,y,z  coordinates  of  the  x-axis  c.g. 

MY 

Real 

Mass  in  the  y-axis  direction 

RY 

R  Vector(3) 

x,y,z  coordinates  of  the  y-axis  c.g. 

MZ 

Real 

Mass  in  the  z-axis  direction 

RZ 

R  Vector(3) 

x,y,z  coordinates  of  the  z-axis  c.g. 

INERTIA 

R  Vector(9) 

Matrix  of  inertias 

PINERTIA 

R  Vl  tor(3) 

Principal  inertias  about  x 

Q 

R  Vector(9) 

Components  of  the  principal  axes 

Module  GPWG 


595 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


OGRIDDSP 

Relation 

Contains  the  displacements  of  the  physical  degrees  of  freedom  that  are  requested 
for  print  or  punch  in  Solution  Control. 


NAME 

TYPE/KEY 

DESCRIPTION 

NITER 

Integer 

Iteration  number 

BCID 

Integer 

The  boundary  condition  number 

DISC 

Integer 

Discipline  flag 

=  1  Statics  =  5  Transien ; 

=  2  Modes  =  6  Frequent  y 

=  3  Steady  Aero  =  7  Buckling 

=  4  Flutter  =  8  Blast 

SUBCASE 

Integer 

Subcase  identification  number 

|  DISPTYPE 

Tbst  (8) 

Label  identifying  the  type  of  the 
displacement  (See  Remark  1) 

CMPLX 

Integer 

Real  or  complex  flag 
=  1  if  real  displacement 
=  2  if  complex  displacement 

GPIDID 

Integer 

External  identification  number  of  the 
physical  point 

SIL 

Integer 

Internal  identification  number  of  the 
physical  point 

FLAG 

Integer 

Flag  indicating  whether  the  point  is  a  grid 
point  or  a  scalar  point 
=  0  for  extra  points 
=  1  for  scalar  points 
=  6  for  structural  nodes 

RDISP 

Real  Vector  (6; 

Real  part  of  the  displacement 

IDISP  |  Real  Vector  (6) 

Imaginary  part  of  the  displacement 

Created  By: 
Notes: 


Many  Modules 

1.  The  DISPTYPE  is  a  textual  key  that  identifies  the  displacement  terms.  The 
following  values  are  used: 

DISPLACE  -  Displacements  of  the  structural  degrees  of  freedom. 

VELOCITY  -  Velocities  of  the  structural  degrees  of  freedom 
ACCEL  -  Accelerations  of  the  structural  degrees  of  freedom. 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


OGRIDLOD 

Relation 

Contains  the  applied  loads,  reaction  forces  and  other  loads  on  t'ti  physical  de¬ 
grees  of  freedom  that  are  requested  for  print  or  punch  in  Solution  Control. 


NAME 

TYPE/KEY 

DESCRIPTION 

NITER 

Integer 

Iteration  number 

BCID 

Integer 

The  boundary  condition  number 

DISC 

Integer 

Discipline  flag 

=  1  Statics  -.  5  Transien 

-  2  Modes  =  7  Buckling 

=  3  Steady  Aero  =  8  Blast 

SUBCASE 

Integer 

Subcase  identification  number 

LOADTYPE 

Text (8) 

Label  identifying  the  type  of  the  load  (see 
remark  1) 

CMP  LX 

Integer 

Real  or  complex  flag 
=  1  if  real  load 
=  2  if  complex  load 

GRIDID 

Integer 

External  identification  number  of  the 
physical  point 

SIL 

Integer 

Internal  identification  number  of  the 
physical  point 

FLAG 

Integer 

Flag  indicating  whether  the  point  is  a  grid 
point  or  a  scalar  point 
•-  0  for  extra  point 
=  1  for  scalar  point 
=  6  for  structural  nodes 

RFORCE 

Real 

Real  part  of  the  applied  load 

I FORCE 

Real 

Imaginary  part  of  the  applied  load 

Many  Modules 


1.  The  LOADTYPE  is  a  textual  key  that  identifies  the  load  terms. 
The  following  values  are  used: 


APPLIED 


RIGID 

FLEXIBLE 

INERTIA 

SPC 


User  defined  applied  load  from  all  disciplines.  For  SAERO, 
the  APPLIED  load  is  computed  and  stored  as  the  sum  of 
RIGID,  FLEXIBLE  and  INERTIA  loads. 

Trimmed  rigid  aerodynamic  load  from  SAERO 
Trimmed  flexible  contribution  to  aerodynamic  load  from 
SAERO 

Inertia  load  contribution  from  SAERO  and  STATICS  with  in¬ 
ertia  relief 

SPC  reaction  forces  for  STATICS,  SAERO,  MODES,  TRAN¬ 
SIENT  and  FREQUENCY. 


597 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


OLOCALDV 

Relation 

Contains  the  local  design  variable  values  that  are  requested  for  print  or  punch  in 
Solution  Control. 


NAME 

TYPE/KEY 

DESCRIPTION 

NITER 

Integer 

Iteration  number 

ETYPE 

Tfext  (8) 

Element  type,  one  of  the  following: 

BAR  CONM2 

ELAS  MASS 

QDMEMI  QUAD4 

ROD  SHEAR 

TRIA3  TRMEM 

EID 

Integer  >  0 

Element  identification  number 

LAYRNUM 

Integer 

Layer  number  (=0  if  noncomposite) 

T 

Real 

Local  design  variable  value  (See  Remark  2) 

11 

Real 

1st  plane  moment  of  inertia  for  BAR 
elements 

12 

Real 

2nd  plane  moment  of  inertia  for  BAR 
elements 

Created  By: 
Notes: 


Module  ACTCON 

1.  Any  local  design  variable  that  are  requested  for  print  or  punch  in  Solution 
Control  at  any  iteration  will  be  stored  in  this  relation. 

2.  For  each  element  type,  T,  II  and  12  have  different  meanings 


BAR 

-  T  is  element  cross-sectional  area 

11  and  12  are  related  moments  of  inertia 

COM2 

-  T  is  concentrated  mass  value 

11  and  12  are  not  used 

ELAS 

-  T  is  spring  stiffness 

11  and  12  are  not  used 

MASS 

-  T  is  mass  value 

I)  and  12  are  not  used 

QDMEMI 

-  T  is  element  or  layer  thickness 

11  and  12  are  not  used 

QUAD4 

-  T  is  element  or  layer  thickness 

11  and  12  are  not  used 

ROD 

-  T  is  element  cross  sectional  area 

11  and  12  are  not  used 

SHEAR 

-  T  is  element  thickness 

11  and  12  are  not  used 

TRIA3 

-  T  is  element  or  layer  thickness 

11  and  12  are  not  used 

TRMEM 

-  T  is  element  or  layer  thickness 

11  and  12  are  not  used 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 

Entity: 
Entity  Type: 
Description: 
Record: 

Created  By: 
Notes: 


OMIT 

Relation 

Contains  the  definition  of  the  degrees  of  freedom  that  the  user  wishes  to  omit 
from  the  analysis  through  matrix  reduction. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

GRID1 

Integer  >  0 

Grid  or  scalar  point  id 

COMPNTS1 

Integer  2: 0 

Component  of  GRID1  to  be  omitted 

Module  IFF 

1.  Used  by  the  MKUSET  module  to  build  the  USET  relation. 

OMIT1 

Relation 

Contains  the  definition  of  the  degrees  of  freedom  that  the  user  wishes  to  omit 
from  the  analysis  through  matrix  reduction. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

COMPNTS1 

Integer  >  0 

Component  of  GRID1  to  be  omitted 

GRID1 

Integer  >  0 

Grid  or  scalar  point  id 

Module  IFP 

1.  Used  by  the  MKUSET  module  to  build  the  USET  relation. 

OTL 

Unstructured 

Contains  a  list  of  output  times  for  each  time  step  set. 

1.  Contains  a  list  of  the  LIDs  of  the  time  step  sets  in  the  Bulk  Data  file, 
i.  Contains  the  output  time  list  for  the  (i-l)th  set  ID. 

Module  PFBULK 

1.  This  entity  is  used  in  the  OFPxxx  modules. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


OPTIMIZE 

Relation 

Contains  the  optimization-dependent  solution  control  requests  as  input  in  the  so¬ 
lution  control  packet. 


NAME 

TYPE/KEY 

DESCRIPTION 

CGRAPRNT 

Integer  vector  (12) 

Constraint  gradient  print  selection 
WORD  1  Print  set  identification 
number  >  0,  or 
=  0  NONE 
=  -1  ALL 
=  -?  LAST 
=  -o  ACTIVE 

WORD  2  Punch  set  identification 
number 

WORD  3  Print  form 
=  0  Rectangular 
=  1  Polar 

WORD  4  Punch  form 

WORD  5  Print  frequency  set 
identification  number 

WORD  6  Punch  frequency  set 
identification  number 

WORD  7  Print  iteration  set 
identification  number 

WORD  8  Punch  iteration  set 
identification  number 

WORD  9  Print  mode  set  identification 
number 

WORD  10  Punch  mode  set 
identification  number 

WORD  11  Print  time  set  identification 
number 

WORD  12  Punch  time  set  identification 
number 

DCONPRNT 

Integer  vector  (12) 

Design  constraint  print  selection 

GDESPRNT 

Integer  vector  (12) 

Global  design  variable  print  selection 

KSNSPRNT 

Integer  vector  (12) 

Element  stiffness  senstivity  print 
selection 

LDESPRNT 

Integer  vector  (12) 

Local  design  variable  print  selection 

MSKSPRNT 

Integer  vector  (12) 

Element  mass  senstivity  print  selection 

OGRAPRNT 

Integer  vector  (12) 

Objective  function  gradient  print 
selection 

BULKPRNT 

Integer  vector  (12) 

Design  model  Bulk  Data  punch  selection 
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Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


NAME 

TYPE/KEY 

DESCRIPTION 

HISTPRNT 

Integer 

Design  iteration  history  print  toggle 

TITLE 

Thxt  (72) 

User  label  TITLE 

SUBTITLE 

Tbxt(72) 

User  label  SUBTITLE 

LABEL 

Ifext  (72) 

User  label  LABEL 

Module  Solution 

1.  The  format  of  the  CGRAPRNT  vector  is  typical  of  the  format  of  all  the  print 
selection  vectors.  Additionally,  the  format  for  the  print  set  Identification  num¬ 
ber  in  the  CGRAPRNT  vector  is  typical  of  that  of  the  other  set  Identification 
numbers  in  the  vector. 

2.  The  CASE,  JOB  and  OPTIMIZE  relation  entities  together  contain  the  solu¬ 
tion  control  requests  as  input  in  the  solution  control  packet.  CASE  contains 
the  case-dependent  parameters,  JOB  contains  the  case-independent  requests 
and  OPTIMIZE  contains  the  optimization-dependent  requests. 

PA 

Matrix 

External  loads  applied  in  the  a-set  derived  from  partitions  of  PF  (see  PG). 

PAA 

Matrix 

Rigid  body  aerodynamic  load  vectors  derived  from  partitions  of  PAF  (see  PAF). 

PAEROl 

Relation 

Contains  a  list  of  associated  bodies  for  panels  used  in  Doublet- Lattice  aerodynam¬ 
ics. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer  >  0 

Property  identification  number 

BODIES 

Integer  Array  (6) 

Array  attribute  containing  the 
identifications  of  associated  bodies 

Module  IFP 

1.  The  BODIES  identification  numbers  refer  to  CAER02  relation  tuples. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


PAER02 

Relation 

Contains  the  definition  of  the  cross-sectional  properties  of  Doublet-Lattice  aerody¬ 
namic  bodies  as  input  from  the  bulk  data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer  >  0 

Property  identification 

ORIENT 

Ttext  (8) 

Type  of  motion  allowed  for  the  body 

WIDTH 

Real  >  0.0 

Reference  half  width  for  the  body 

AR 

Real  >  0.0 

Aspect  ratios  for  the  body 

LRSB 

Integer  >  0 

AEFACT  identification  number  containing 
the  half  widths  of  slender  bodies 

LRIB 

Integer  >  0 

AEFACT  identification  number  containing 
the  half  widths  of  interference  bodies 

LTH1 

Integer  >  0 

AEFACT  identification  number  that  has 
the  first  array  of  theta  values 

LTH2 

Integer  >  0 

AEFACT  identification  number  that  has 
the  second  array  of  theta  values 

THI1 

Integer  >  0 

First  interference  element  using  the 

LTH1  theta  distribution 

THN1 

Integer  >  0 

Last  interference  element  using  the 

LTH1  theta  distribution 

THI2 

Integer  >  0 

First  interference  element  using  the 

LTH2  theta  distribution 

THN2 

Integer  £  0 

Last  interference  element  using  the 

LTH2  theta  distribution 

THI3 

Integer  >  0 

First  interference  element  after  THN2  that 
uses  the  LTH1  theta  distribution 

THN3 

Integer  >  0 

Last  interference  element  after  TKN2  that 
uses  the  LTH1  theta  distribution 

Module  IFF 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 
Entity  Type: 
Description: 
Matrix  Form: 
Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 


PAER06 

Relation 

Contains  the  definition  of  analysis  parameters  for  bodies  in  the  aerodynamic 
model  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

BCID 

Integer  >  0 

Body  component  identification  number 

ACMPNT 

Tfext  (8) 

Component  type  (i.e.  FUSEL) 

CP 

Integer  >  0 

Coordinate  system  in  which  geometry 
inputs  are  given 

GROUP 

Integer  2  0 

Group  identification  number 

NRAD 

Integer  2  0 

Number  of  equal  radial  cuts  used  to  define 
body  panels 

LRAD 

Integer  2  0 

AEFACT  set  identification  number  for  the 
angular  locations  of  body  panels 

AXIAL 

Integer  2  0 

AEFACT  set  identification  number  for  the 
axial  locations  of  body  panels 

Module  IFF 


PAF 

Matrix 

Rigid  body  load  vectors  multiplied  by  dynamic  pressure. 
See  AIRFRC  for  the  dimensions. 

MAPOL 


1.  This  matrix  is  the  dynamic  pressure  times  AIRFRC. 

2.  The  MAPOL  sequence  supports  the  following  partitions  of  the  PAF  matrix 
(see  the  Theoretical  Manual  for  the  * — 'nlicit-  formation  of  these  submatrices): 


PAF  -> 


PQARO 
PA A 


PA A  -> 


PAL 

PABBAR 


PAL 

Matrix 

A  partition  of  PAA  (see  PAF). 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Entity: 
Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


PAR 

Subscripted  Matrix 

An  intermediate  matrix  formed  during  the  performance  of  an  aeroelastic  trim 
analysis. 

The  number  of  rows  is  equal  to  the  number  of  degrees  of  freedom  in  the  1-set 
while  the  number  of  columns  is  equal  to  the  numbei  of  rigid  body  load  vectors 
from  AIRFRC. 

MAPOL  using  GFBS 

1.  PAR  is  the  solution  of: 

[JQLll  ]  [PAR  ]  =  [PI  ] 

2.  Since  PAR  is  needed  in  the  sensitivity  analysis,  it  is  subscripted  by  boundary 
condition. 

PARBAR 

Matrix 

A  partition  of  the  PAA  (see  PAF). 

PARL 

Subscripted  Matrix 

Contains  the  partitioning  vector  to  partition  those  degrees  of  retained  for  analy¬ 
sis  (a-set)  into  those  reduced  out  (r-set)  and  those  left  over  (1-set). 

A  variable-sized  single  precision  column  vector  having  one  row  for  each  degree  of 
freedom  retained  for  analysis.  Degrees  of  freedom  in  the  reduce  set  are  denoted 
by  a  real  0.0  and  those  left  over  by  a  real  1.0. 

Module  MKUSET 

1.  The  dimension  of  this  subscripted  matrix  must  be  large  enough  for  all  optimi¬ 
zation  and  analysis  boundary  conditions. 

2.  This  vector  is  modified  by  the  GDR  modules  if  Generalized  Dynamic  Reduc¬ 
tion  is  used. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 
Entity  Structure: 

Created  By: 
Notes: 


PBAR 

Relation 

Contains  the  property  definition  for  the  BAR  element  as  input  from  the  Bulk 
Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer  >  0,  key 

Property  identification  number 

MIDI 

Integer  >  0 

Material  property  identification 
number  of  the  MAT1  tuple 

AREA 

Real  >  0.0 

Element  cross-sectional  area 

11 

Real 

Area  moment  of  inertia  in  plane  1 

12 

Real 

Area  moment  of  inertia  in  plane  2 

TORSION 

Real 

Tbrsional  constant 

NSM 

Real  £  0.0 

Element  nonstructural  mass 

TMIN 

Real 

Minimum  cross-sectional  area  in 
design 

Cl,  C2,  Dl,  D2 

Real 

Element  stress  recovery  coefficients 

El,  E2,  FI,  F2 

Real 

KFACT1 

Real 

Area  factor  for  shear  (plane  1) 

K FACT 2 

Real 

Area  factor  for  shear  (plane  2) 

112 

Real 

Area  product  of  inertia 

R1SQR 

Real 

Multiplicative  factor  to  determine 

11  in  design 

R2SQR 

Real 

Multiplicative  factor  to  determine 

12  in  design 

ALPHA 

Real 

Exponential  power  associated  with 
the  design  variable. 

Module  EFP 


PCAS 

Unstructured 

Identifies  active  constraints  for  the  current  boundary  condition. 

A  single  record  of  integers  whose  length  is  equal  to  the  number  of  constraints  ac¬ 
tive  in  the  current  boundary  condition. 

Module  ABOUND 

1.  There  is  one  integer  for  each  active  constraint.  The  integer  is  set  to  the  sub¬ 
case  number  of  the  constraint  (see  the  CONST  relation). 
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Entity: 

Entity  Type: 
Description: 

Elation  Attributes: 


Created  By: 
Notes: 


PCCMP 

Relation 

Contains  the  property  definitions  for  a  multiple  ply  composite  material  laminate 
as  input  trot  i  tie  Bulk  Data  file 


NAME 

TYPE/KEY  \  DESCRIPTION 

PID 

Integer  >  0 

Property  identification  number 

ZO 

Real 

The  distance  from  the  plane  of  the  grid 
points  to  the  bottom  surface 

NSM 

Real  >0.0 

nonslructural  mass  per  unit  area 

SBOND 

Real  >  0.0 

Allowable  shear  stress  of  bending  material 

FAILCRIT 

.  _  _ 

'fcxt  (8) 

Theory  used  to  predict  failure 

THIN 

Real 

Minimum  layer  thicknesses  for  design 

LOPT 

Ttext  (81 

Laminate  generation  option 

MIDI 

Integer  >  0 

Ply  material  identification 

TKICKI 

Integer  0 

r 

Ply  thickness 

THETAI 

i.?rd  _j 

Ply  material  orientation  angle 

SOUTI 

Tfext,  (8) 

Flag  for  stress  output 

Module  IFF 


1.  This  relation  wilt  contain  one  tuple  for  each  ply  in  each  unique  PID. 
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Entity: 

Entity  Type: 
Description: 

Entity  Structure: 


Created  By: 


PCCMPS 

Unstructured 

Contains  one  record  for  each  PCOMPi  Bulk  Data  type  entry.  Data  includes  the 
PCOMPi  entry  and  its  intrinsic  laminate  property  data. 


Record 

Word 

Type 

Description 

1 

1-2 

ltext 

PCOMP 

3 

Integer  >  0 

PID-Property  identification 
number 

4 

Integer  >  0 

N-Number  of  layers 

5(11+4*N) 

RSP 

Remainder  of  PCOMP  data 

(12+4*N)-(3 1*N+ 11) 

RSP 

Layer  Property  data 

(31*N+12)-(31*N+13) 

RSP 

Laminate  Bending  Inertia 

(3 1*N+ 14)-(3 1*N+ 15) 

RSP 

Laminate  Neutral  Surface 
Location 

|  Words  3  through  31*N+15  are  repeated  for  each  PCOMP  Bulk  Data  entry.  j 

2 

1-2 

Text 

PCOMPI 

3 

Integer  >  0 

PID-Property  identification 
number 

4 

Integer  >  0 

N-Numbers  of  layers 

5-C12+N) 

RSP 

Remainder  of  PCOMPI  data 

(13+NH37+N) 

RSP 

Layer  property  data 

(38+N)-(39+N) 

RSP 

Laminate  Bending  Inertia 

(40+N)-(41+N) 

RSP 

Laminate  Neutral  Surface 
Location 

Words  3-41+N  are  repeated  for  each  PCOMPI  Bulk  Data  entry.  j 

3 

1-2 

Ifext 

PCOMP2 

3 

Integer  >  0 

PID-Property  identification 
number 

4 

Integer  >  0 

N-Number  of  layers 

5-(ll+2*N) 

RSP 

Remainder  of  PCOMP2  data 

(12+2*N)-(36+2*N) 

RSP 

Layer  property  data 

(37+2*N)-(38+2*N) 

RSP 

Laminate  Bending  Inertia 

(39+2*N)-(40+2*N) 

RSP 

Laminate  Neutral  Surface 
Location 

Words  3-40+2*N  are  repeated  for  each  PCOMP2  Bulk  Data  entry. 

Module  EMG 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


PCOMP1 

Relation 

Defines  the  property  of  a  n-ply  laminated  composite  material  where  all  plies  are 
composed  of  the  same  material  and  are  of  equal  thickness. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer  >  0 

Property  identification  number 

ZO 

Real 

Offset  of  the  element  reference  plane  from  the 
plane  of  grid  points 

NSM 

Real  >  0.0 

nonstructural  mass  per  unit  area 

SBOND 

Real  >  0.0 

Allowable  shear  stress  of  the  bending  material. 

FAILCRIT 

Tbxt  (8) 

Failure  theory  to  predict  ply  failure 

TMIN 

Real  >  0.0 

Minimum  layer  thickness  for  design 

MID 

Integer  >  0 

Ply  material  identification 

LOPT 

Tfext  (8) 

Lamination  generation  option 

THICK 

Real  >  0.0 

Ply  thickness 

THETAI 

Real 

Ply  material  orientation  angle 

Module  IFP 


1.  This  relation  will  contain  one  tuple  for  each  ply  for  each  unique  PID. 
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Entity: 

EntityType: 

Description: 

Relation  Attributes: 


Created  By: 
Notes: 

Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


PCOMP2 

Relation 

Defines  the  properties  of  a  n-ply  laminated  composite  material  where  all  plies  are 
of  the  same  material. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer  >  0 

Property  identification  number 

ZO 

Real 

Offset  of  the  element  reference  plane  from 
the  plane  of  grid  points. 

NSM 

Real  >  0.0 

Nonstructural  mass  per  unit  area 

SBOND 

Real  >  0.0 

Allowable  shear  stress  of  the  bonding 
material. 

FAILCRIT 

'Itext  (8) 

Failure  theory  to  predict  ply  failure 

TMIN 

Real  >  0.0 

Minimum  layer  thickness  for  design 

MID 

Integer>  0.0 

Ply  material  identification 

LOPT 

'Itext  (8) 

Lamination  generation  option 

THICKI 

Real  >  0.0 

Ply  thickness 

THETAI 

Real 

Ply  material  orientation  angle 

Module  IFP 


1.  The  relation  will  contain  one  tuple  for  each  ply  for  each  unique  PID. 

PDF 

Matrix 

Applied  loads  matrix  for  frequency  response  analysis. 

Complex  matrix  with  one  column  for  each  frequency  at  which  frequency  response 
results  are  to  be  computed.  This  matrix  is  applicable  for  both  the  direct  and  mo¬ 
dal  methods  of  solution  so  that  the  number  of  rows  equal  to  the  number  of  de¬ 
grees  of  freedom  in  the  d-  or  h-sets,  depending  on  the  method  of  solution. 

Module  DYNLOAD 

1.  This  matrix  is  also  for  applied  gust  loads  if  the  gust  discipline  option  of  fre¬ 
quency  response  is  selected. 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


PDT 

Matrix 

Applied  loads  matrix  for  transient  response  analysis. 

Complex  matrix  with  one  column  for  each  frequency  at  which  transient  response 
results  are  to  be  computed.  This  matrix  is  applicable  for  both  the  direct  and  mo¬ 
dal  methods  of  solution  so  that  the  number  of  rows  equal  to  the  number  of  de¬ 
grees  of  freedom  in  the  d-  or  h-sets,  depending  on  the  method  of  solution. 

Module  DYNLOAD 

PE  LAS 
Relation 

Contains  the  property  data  for  scalar  spring  elements  as  input  from  the  Bulk 
Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer,  key 

Property  identification  number 

K 

Real 

Spring  constant 

DAMPCOEF 

Real 

Damping  coefficient 

STRSCOEF 

Real 

Stress  coefficient 

TMIN 

Real 

. 

Minimum  spring  constant  value  for  design 

Module  IPF 
PF 

Matrix 

External  loads  in  the  f-set  derived  from  partitions  of  PN  (see  PG). 


PFGLOAD 


Matrix 

Applied  loads  matrix  on  the  physical  degrees  of  freedom  for  the  frequency  depend¬ 
ent  loads  in  the  current  boundary  condition. 

Complex  rectangular  matrix  with  one  row  for  each  physical  degree  of  freedom 
and  one  column  for  each  frequency  step  in  each  frequency  analysis  in  the  current 
boundary  condition. 

Module  DYNLOAD 

1.  This  matrix  is  formed  only  if  the  LOAD  print  request  for  the  FREQUENCY 
discipline  is  set  fot  the  current  boundary  condition. 
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Entity: 

PFCSA 

Entity  Type: 

Subscripted  Matrix 

Description: 

Contains  the  partitioning  vector  to  partition  the  free  degrees  of  freedom  (f-set) 
into  the  omitted  degrees  of  freedom  (o-set)  and  those  retained  for  analysis  (a-set). 

Matrix  Form: 

A  variable-sized  single-precision  column  vector  containing  one  row  for  every  free 
degree  of  freedom.  Degrees  of  freedom  in  the  o-set  are  denoted  by  real  0.0  and 
those  in  the  a-set  by  real  1.0. 

Created  By: 

Module  MKUSET 

Notes: 

1.  The  dimension  of  this  subscripted  matrix  must  be  large  enough  for  all  optimi¬ 
zation  and  analysis  boundary  conditions. 

2.  This  matrix  is  modified  by  the  GDR  modules  if  Generalized  Dynamic  Reduc¬ 
tion  is  used. 

Entity: 

PG 

Entity  Type: 

Matrix 

Description: 

Contains  the  global  loads  matrix  for  the  current  boundary  condition. 

Matrix  Form: 

A  variable-size  matrix  having  one  row  for  each  structural  degree  of  freedom  in 
the  model  and  one  column  for  each  load  condition  in  the  cuiTent  boundary  condi¬ 
tion. 

Created  By: 

Module  GTLOAD 

Notes: 

1.  This  matrix  is  flushed  and  re-formed  for  each  boundary  condition  in  the  prob- 

lem. 

2.  The  MAPOL  sequence  supports  the  following  partitions  of  the  PG  matrix  (see 
Theoretical  Manual  for  the  explicit  formation  of  these  submatrices). 


Entity:  PGA 

Entity  Type:  Matrix 

Description:  Partitioning  vector  for  active  load  cases. 

Matrix  Form:  One  column  with  the  numbers  of  rows  equal  to  the  number  of  subcases  for  the 

current  boundary  condition. 

Created  By:  Module  ABOUND 

Notes: 

1.  Active  subcases  are  designated  by  a  value  of  1.0,  inactive  subcases  by  0.0. 


611 


Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 


PGMN 

Subscripted  Matrix 

Contains  the  partitioning  vector  to  partition  the  structural  degrees  of  freedom  (g- 
set)  into  the  dependent  multi-point  constraint  set  (m-sefc)  and  the  independent,  set 
(n-  set). 

A  variable-sized  single  precision  column  vector  containing  one  row  for  each  struc¬ 
tural  degree  of  freedom  in  the  model.  Degrees  of  freedom  in  the  m-set  are  de¬ 
noted  by  real  0.0  and  those  in  the  n-set  by  real  1.0. 

Module  MKUSET 

PHIA 

Matrix 

Contains  the  eigenvectors  in  the  analysis  degrees  of  freedom  for  each  vector  com¬ 
puted. 

A  variable-sized  vector  having  one  column  for  each  computed  eigenvector  and  one 
row  for  each  degree  of  freedom  in  the  analysis  set  for  the  current  boundary  condi¬ 
tion. 

Module  REIG 

1.  See  PHIG  for  data  recovery. 

PH  IB 
Matrix 

Matrix  of  modes  shapes  used  in  nuclear  blast  response. 

Real  rectangular  matrix  with  one  row  for  each  a-set  degree  of  freedom  and  one 
column  for  each  retained  mode. 

MAPOL 

1.  PHIB  is  obtained  by  merging  PHIR  and  PHIE. 

PHIE 

Matrix 

Matrix  of  elastic  mode  shapes  used  in  nuclear  blast  response. 

Real  rectangular  matrix  with  one  row  for  each  a-set  degree  of  freedom  and  one 
column  for  each  retained  elastic  mode. 

MAPOL 
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Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 

Entity: 
Entity  Type: 
Description: 

Entity: 
Entity  Type: 
Description: 


PHIF 

Matrix 

Normal  modes  in  the  f-set  recovered  from  PHIA  and  PHIO  (see  PHIG). 


PHIG 

Subscripted  Matrix 

Contains  the  eigenvectors  in  the  global  set  computed  in  the  REIG  module. 

A  variable-sized  matrix  having  one  column  for  each  eigen  vector  computed  and 
one  row  for  each  structural  degree  of  freedom. 

MAPOL 


1.  The  MAPOL  sequence  recovers  this  matrix  in  the  following  order: 
[  PHIO  ]  -  [  GSVBO  ]  *  [  PHIA  ] 

PHI F 


PHIA 

PHIO 


YS 

PHIF 

VM.  * 

XM 

PHIN 


->  PHIS 

=  [  TMN  ]  *  [  PHIN  ] 

PHIG 


*UM  contains  modes  in  the  m-set.  The  entity  is  reused  in  the  MAPOL  se¬ 
quence. 


PHIKH 

Matrix 

Normal  mode  shapes  splined  to  the  aerodynamic  panels. 

Real  rectangular  matrix  with  one  row  for  each  aerodynamic  degree  of  freedom 
and  one  column  for  each  normal  mode. 

Module  QHHLGEN 


PHIN 

Matrix 

Modes  in  the  n-set,  recovered  from  PHIF  (see  PHIG). 


PHIO 

Matrix 

Mode  shapes  for  omitted  degrees  of  freedom  (see  PHIG). 
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Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


PH  I  OK 
Matrix 

Approximate  mode  shapes  produced  by  generalized  dynamic  reduction. 

Real  rectangular  matrix  with  one  row  for  each  o-set  degree  of  freedom  and  one 
column  for  each  approximate  mode  shape. 

Module  GDR2 

1.  This  matrix  is  computed  for  generalized  dynamic  reduction  and  only  if  there 
are  k-set  degrees  of  freedom. 

PHIR 

Matrix 

Matrix  of  rigid  body  shapes  used  in  nuclear  blast  response. 

Real  rectangular  matrix  with  one  row  for  each  a-set  degree  of  freedom  and  one 
column  for  each  retained  rigid  body  mode. 

MAPOL 

1.  This  matrix  is  created  by  performing  a  RGWMERGE  using  matrices  D  and 
ID2  and  partiton  vector  MPART. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 

Entity: 
Entity  Type: 
Description- 


PIHEX 

Relation 

Contains  the  property  data  for  an  isoparametric  hexahedron  element  as  input 
from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer  >  0,  key 

Property  identification  number 

MID 

Integer  >  0 

Material  identification  number 

CID 

Integer  >  0 

Identification  number  of  the  coordinate 
system  in  which  the  material  referenced  by 
MID  is  defined 

NIP 

Integer  =  2, 3, 4 

Number  of  integration  points  along  each 
edge  of  the  element 

AR 

Real  >  1.0 

Maximum  aspect  ratio  (ratio  of  longest  to 
shortest  edge)  of  the  element 

ALFA 

Real, 

0.0£ALFA^180.0 

Maximum  angle  in  degrees  between  the 
normals  of  two  subtriangles  comprising  a 
quadrilateral  face 

BETA 

Real, 

0.0<BETA<180.0 

Maximum  angle  in  degrees  between  the 
vector  connecting  a  corner  point  to  an 
adjacent  midside  point  and  the  vector 
connecting  that  midside  point  and  the 
other  midside  or  corner  point 

Module  IFP 


PLBAR 

Matrix 

A  partition  of  matrix  PA  (see  PG). 
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Entity:, 

Entity  Type: 
Description- 

Relation  Attributes: 


PLIST 


Relation 

Contains  the  property  types  and  identification  numbers  associated  with  a  design 
variable. 


< 


NAME 

TYPE/KEY 

DESCRIPTION 

LTNKID 

Integer  >  0,  key 

Design  variable  identification 

PTYPE 

Tfext  (8) 

Property  relation  identifier 

PID1 

Integer  >  0 

Property  identification 

Created  By: 
Notes: 


Module  IFP 


1.  The  PTYPE  is  the  name  of  the  relation  in  which  the  PID  associated  with  the 
design  variable  is  found. 

2.  This  relation  contains  one  tuple  for  each  PID  associated  with  each  PTYPE 
listed  in  each  unique  LINKED. 

3.  Allowable  PTYPE  entries  are: 

PROD  PCOMP,  PCOMP1,  PCOMP2 

PSHEAR  PMASS 

PQDMEM  PSHELL 

PTRMEM  PELAS 

PBAR 


Entity:  PLOAD 

Entity  Type:  Relation 

Description:  Contains  the  load  information  defined  over  a  triangular  or  quadrilateral  region 

as  input  from  the  Bulk  Data  file. 

Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

SCALE 

Real 

Scale  factor 

GRID1,  GRID2 

Integer  >  0 

Grid  points  defining  region  of  load 
application 

GRID3,  GRID4 

Integer  >  0 

Created  By:  Module  IFP 

Notes: 

1.  The  GRID4  entry  is  zero  if  a  triangular  region  is  defined. 


i 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


PLYLIST 

Relation 

Contains  a  list  of  composite,  layers  as  input  in  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

PLY 

Integer  >  0 

Ply  number 

Module  IFP 

1.  This  relation  contains  one  tuple  for  each  ply  in  each  set. 
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Entity: 

Entity  'type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 
Entity  Type: 
Desmption: 

Matrix  Form: 

Created  By: 
Notes: 


PMASS 


Relation 


Contains  the  mass  value  of  a  scalar  mass  element  as  input  from  the  Bulk  Data 
file. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer  >  0,  key 

Property  identification  number 

MASS 

Real 

Mass  value 

TMIN 

Real  >  0.0 

Minimum  mass  value  for  design 

Module  IFP 

PMAXT 

Matrix 

Contains  the  maximum  thickness  design  variable  based  on  the  user’s  defined 
maximum  (laminate)  thickness. 

[  t  ]  =  [  PMAXT  f  *  [  v  ]  +  [  VFIXV  ] 

A  variable-sized  single  precision  matrix  having  one  column  for  each  shape  func¬ 
tion  designed  laminate  or  element  and  one  row  for  each  global  design  variable. 
The  terms  in  PMAXT  are  the  sum  of  the  PTRANS  columns  associated  with  one 
laminate  (if  composite). 

Module  MAKEST 

1.  If  a  layered  composite  has  some  undesigned  laminae,  the  VFIXD  entity  con¬ 
tains  the  terms  needed  to  calculate  the  fixed  contribution. 

2.  If  no  shape  function  linking  is  used,  this  matrix  will  have  no  columns. 
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Entity: 

Entity  ^type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 


PMINT 

Matrix 

Contains  the  minimum  thickness  variable  linking  terms  based  on  the  user’s  de¬ 
fined  minimum  (laminate)  thickness. 

[  t  ]  =  [  PMZNT  ]T  *  [  v  ] 

A  variable-size  single  precision  matrix  that  has  one  column  for  each  element  de¬ 
signed  by  shape  (unction  linking  and  one  row  for  each  global  design  variable. 
The  terms  in  PMINT  are  the  PTRANS  column  for  the  shape  function  designed 
element  divided  by  the  user  input  minimum  (laminate)  thickness. 

Module  MAKEST 

1.  If  no  shape  function  linking  is  used,  this  matrix  will  have  no  columns. 

PN 

Matrix 

External  loads  applied  in  the  n-set  derived  from  PG  (see  PG). 

PNSF 

Subscripted  Matrix 

Contains  the  partitioning  vector  to  partition  the  independent  degrees  of  freedom 
(n-set)  into  the  dependent  single  point  constraint  set  (s-set)  and  the  free  degrees 
of  freedom  (f-set). 

A  variable-sized  single  precision  column  vector  containing  one  row  for  each  inde¬ 
pendent  degree  of  freedom.  Degrees  of  freedom  in  the  s-set  are  denoted  by  real 
0.0  and  those  in  the  f-set  by  real  1.0. 

Module  MKUSET 
PO 

Matrix 

A  partition  of  the  PF  matrix  (see  PG). 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 
Entity  Type: 
Description: 


POARO 

Subscripted  Matrix 

Matrix  of  aerodynamic  “unit”  loads  applied  to  omitted  degrees  of  freedom. 

Real  rectangular  matrix  with  one  row  for  each  o-set  degree  of  freedom  and  the 
same  number  of  columns  ar  the  AIRFRC  matrix. 

MAPOL 

1.  The  Matrix  may  be  required  in  the  static  aeroelastic  sensitivity  analysis  and 
is  therefore  subscripted  by  the  boundary  condition. 

PQDMEM1 

Relation 

Contains  the  properties  of  the  isoparametric  quadrilateral  membrane  element  as 
input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer  >  0,  key 

Property  identification  number 

MIDI 

Integer  >  0 

Material  identification  number 

THICK 

Real>  0.0 

Element  thickness 

NSM 

Real  >0 

Element  nonstructural  mass 

TMIN 

Real  SO 

Minimum  thickness  for  design 

Module  IFP 
PR 

Matrix 

A  partition  of  the  PA  matrix  (see  PG). 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 


PROD 

Relation 

Contains  the  property  data  for  ROD  elements  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer  >  0,  key 

Property  identification  number 

MIDI 

Integer  >  0 

Material  identification  number  of  a  MAT1 
tuple 

AREA 

Real  5  0.0 

Element  cross  sectional  area 

TORSION 

Real  £  0.0 

Tbrsional  constant 

STRSCOEF 

Real 

Stress  recovery  coefficient 

NSM 

Real  £  0.0 

Element  nonstructural  mass 

TMIN 

Real  5  0.0 

Minimum  cross-sectional  area  for  design 

Module  IFP 
PS 

Matrix 

A  partition  of  the  PN  matrix  (see  PG). 

PSHEAR 

Relation 

Contains  the  property  data  for  the  shear  panel  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer  >  0,  key 

Property  identification  number 

MIDI 

Integer  >  0 

Material  identification  number 

THICK 

Real  >  0 

Element  thickness 

NSM 

Real  £  0.0 

Element  nonstructural  mass 

TMIN 

Real  £  0.0 

Minimum  thickness  for  design 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


PSKELL 

Relation 

Contains  the  membrane,  bending,  shear  and  coupling  properties  of' thin  two-di¬ 
mensional  elements  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer  >  0,  key 

Property  identification  number 

MIDI 

Integer  >  0 

Membrane  material  id 

THICK 

Real  >  0 

Element  default  thickness 

MID2 

Integer  >  0 

Bending  material  id 

BENDSTIF 

Real 

Bending  stiffness  parameter 

MID3 

Integer  >  0 

Transverse  shear  material  id 

TRNSVRS 

Real 

Transverse  shear  thickness  divided  by  the 
membrane  thickness 

NSM 

Real  >0.0 

Element  nonstructural  mass 

FZ1,  FZ2 

Real 

Fiber  distances  for  stress  computation 

MID4 

Real  >  0 

Membrane-bending  coupling  material 
identification 

CID2 

Integer 

Material  coordinate  system  identification 
number 

THETAM 

Real 

Material  orientation  angle 

CIDS 

Integer 

Stress  recovery  coordinate  system 

THETAS 

Real 

Stress  recovery  orientation  angle 

OFFST1 

Integer 

Offset  of  the  mid  plane  from  the  plane  of 
the  grid  points 

TMIN 

Real  >  0.0 

Minimum  thickness  for  design 

Created  By: 


Module  IFP 


Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 

Entity: 
Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


PTGLOAD 

Matrix 

Applied  loads  matrix  on  the  physical  degrees  of  freedom  for  the  time  dependent 
loads  in  the  current  boundary  condition. 

Real  rectangular  matrix  with  one  row  for  each  physical  degree  of  freedom  and 
one  column  for  each  time  step  in  each  transient  analysis  in  the  current  coundary 
condition. 

Module  DYNLOAD 

1.  This  matrix  is  formed  only  if  the  LOAD  print  request  for  the  transient  disci¬ 
pline  is  set  for  the  current  boundary  condition. 

PTRANS 

Matrix 

Contains  the  linking  information  for  design  variables  if  the  model  has  design  vari¬ 
ables  defined. 

{  t  }  =  [  PTKANS  ]T  {  v  } 

A  variable-sized  single  precision  matrix  having  one  column  for  each  local  design 
variable  and  one  row  for  each  global  design  variable. 

Module  MAKEST 

1.  This  matrix  is  empty  if  the  model  contains  no  design  variables. 

2.  A  column  of  PTRANS  is  the  sensitivity  of  the  local  variable  to  the  global  vari¬ 
able. 

PTRMEM 

Relation 

Contains  the  property  data  for  the  constant  strain  triangle  as  input  from  the 
Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

PID 

Integer  >  0,  key 

Property  identification  number 

MIDI 

Integer  >  0 

Material  identification  number  of  MAT1  or 
MAT2  tuple 

THICK 

Real  >  0.0 

Element  thickness 

NSM 

Real  £  0.0 

Element  nonstructural  mass 

TMIN 

Real  >  0.0 

Minimum  thickness  for  design 

Module  IFP 


623 


Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 


PI 

Matrix 

Applied  loads  matrix  created  when  there  are  unrestrained  structural  degrees  of 
freedom. 

Real,  rectangular  matrix  with  one  row  for  each  a-set  degree  of  freedom  and  one 
column  for  each  subcase  or  column  in  the  PAF  matrix,  depending  on  whether  a 
static  analysis  or  a  static  aeroela3tic  analysis  is  being  performed. 

MAPOL 

P2 

Matrix 

Applied  loads  matrix  created  when  there  are  unrestrained  structural  degrees  of 
freedom. 

Real,  rectangular  matrix  with  one  row  for  each  r-set  degree  of  freedom  and  one 
column  for  each  subcase  or  column  in  the  PAF  matrix,  depending  on  whether  a 
static  analysis  or  a  static  aeroelastic  analysis  is  being  performed. 

MAPOL 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


QDMM1EST 

Relation 

Contains  the  element  summary  data  for  the  isoparametric  quadrilateral  mem¬ 
brane  element. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0 

Element  identification  number 

PID 

Integer  >  0 

Element  property  identification  number 

PTYPE 

Text (8) 

Element  property  type 

LAYRNUM 

Integer  >  0 

Composite  layer  number 

SIL1 

Integer  >  0 

Internal  grid  point  id 

SIL2 

Integer  >  0 

SIL3 

Integer  >  0 

SIL4 

Integer  >  0 

CID 

Integer  >  0 

Coordinate  system  defining  material  axis 

THETA 

Real 

Material  orientation  angle  for  anisotropic 
material  behavior 

MIDI 

Integer  £  0 

Material  id  of  MAT  1  or  MAT2  tuple 

THICK 

Real  >  0.0 

Element  thickness 

NSM 

Real  £  0.0 

Element  nonstructural  mass 

COORD 1 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  SIL1 

XI,  Yl,  Z1 

Real 

Basic  coordinates  of  SIL1 

COORD2 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  SIL2 

X2,  Y2,  Z2 

Real 

Basic  coordinates  of  SIL2 

COORD3 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  SIL3 

X3,  Y3,  Z3 

Real 

Basic  coordinates  of  SIL3 

COORD4 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  SIL4 

X4 ,  Y4,  Z4 

Real 

Basic  coordinates  of  SIL4 

SCON 

Integer 

Stress  constraint  flag 

DESIGN 

Integer 

Design  flag 

STHRM 

Real  Array 
(3) 

Thermal  stress  terms  for  the  constrained 
element  | 
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Created  By. 
Notes: 


Entity: 

Entity  Type: 
Description: 

Matrix  Form: 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


NAME 

TYPE/KEY 

DESCRIPTION 

STHRMA 

Real  Array 
(3) 

Thermal  strain  terms  for  the  constrained 
element 

TREFTP 

Integer  £  0 

Pointer  to  the  TREF  entity  for  thermal 
loads/stress  evaluation  of  the  designed  element 

Module  MAKEST 

1.  This  relation  is  built  from  the  CQDMEM1,  associated  P-type  and  the  basic 
grid  point  data.  It  contains  one  tuple  for  each  quadrilateral  membrane  ele¬ 
ment  in  the  problem. 

2.  A  nonzero  SCON  flag  denotes  that  the  element  is  affected  by  a  stress  con¬ 
straint. 

3.  A  nonzero  DESIGN  flag  denotes  that  the  element  is  affected  by  a  design  vari¬ 
able. 

4.  LAYRNUM  is  zero  for  noncomposite  elements. 

QEE 

Matrix 

A  partition  of  the  GENQ  matrix  that  contains  only  elastic  degrees  of  freedom. 

Used  in  the  nuclear  blast  response  analysis. 

Real  square  matrix  with  the  number  of  rows  and  columns  equal  to  the  number  of 

elastic  modes  retained  for  the  blast  analysis.Created  By: 

MAPOL 


QHHL 

Matrix 

Matrix  list  of  generalized  unsteady  aerodynamic  coefficients. 

Complex  rectangular  matrix  with  one  row  for  each  retained  mode  shape  and  with 
the  number  of  columns  equal  to  the  product  of  the  number  of  retained  mode 
shapes  and  the  number  of  M-k  pairs  at  which  aerodynamics  are  required. 

Module  QHHLGEN 

1.  The  matrix  may  be  required  in  the  flutter  sensitivity  analysis  and  is  therefore 
subcribed  by  boundary  condition. 
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Entity: 
Entity  Type: 
Description: 
Matrix  Form 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 


Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


QHJL 

Matrix 

Generalized  aerodynamic  data  for  the  gust  loads  determination. 

A  variable-sized  matrix  list.  Each  Mach  number  and  reduced  frequency  required 
in  the  gust  analysis  creates  a  matrix  with  one  row  for  each  retained  mode  panel 
and  one  volumn  for  each  aerodynamic  panel. 

QHHLGEN 

1.  See  QJKL 

2.  The  order  of  the  matrices  in  the  list  is  the  order  of  m-k  pairs  in  UNMK 

QJJL 

Matrix 

Matrix  list  of  unsteady  aerodynamic  coefficients. 

Complex  rectangular  matrix  with  one  row  for  each  aerodynamic  panel  and  with 
the  number  of  columns  equal  to  the  product  of  the  number  of  aerodynamic  panels 
and  the  number  of  M-k  pairs  at  which  aerodynamics  are  required. 

Module  AMP 

1.  This  matrix  list  is  generated  only  if  there  is  a  requirement  for  nuclear  blast 
analysis. 

2.  The  matrix  components  in  QJJL  are  the  inverse  of  the  transpose  of  the  ma¬ 
trix  components  of  matrix  AJJTL  associated  with  BLAST  analyses. 

QKJL 

Matrix 

Aerodynamic  interpolation  list  containing  data  required  for  gust  analysis. 

A  variable-sized  matrix  list.  There  is  an  nk  by  nj  matrix  for  each  Mach  number 
and  reduced  frequency  required  in  the  gust  analysis. 

Module  AMP 

1.  The  order  of  the  matrices  in  the  list  is  the  order  of  m-k  pairs  in  UNMK 

2.  One  matrix  QKJ  is  generated  for  each  M-k  pair  associated  with  gust  analyses. 
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Entity: 

Entity  Type: 
Description: 
Matrix  Form: 


Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 
Matrix  Form: 


Created  By: 


QKKL 

Matrix 

Matrix  list  of  unsteady  aerodynamic  coefficients. 

Complex  rectangular  matrix  with  one  row  for  each  aerodynamic  degree  of  free¬ 
dom  and  with  the  number  of  columns  equal  to  the  product  of  the  number  of  aero¬ 
dynamic  degrees  of  freedom  and  the  number  of  M-k  pairs  at  which  aerodynamics 
are  required. 

Module  AMP 

1.  The  matrix  components  of  this  list  are  generated  from: 

[QKK  ]  =  [SKJ]  *  [AJJT]"7  *  [V]  +  jjOltJK  +  (±k  }D2JKj 

2.  One  matrix  QKK  is  generated  for  each  M-k  pair  associated  with  flutter  or 
gust  analyses. 

QRE 

Matrix 

A  partition  of  the  GENQ  matrix. 

Real  rectangular  matrix  with  the  number  of  rows  equal  to  the  number  of  rigid 
body  modes  and  the  number  of  columns  equal  to  the  number  of  elastic  modes  re¬ 
tained  for  the  blast  analysis. 

MAPOL 


Entity: 

Entity  Type: 
Description: 
Matrix  Form; 

Created  By: 


QRR 

Matrix 

A  partition  of  the  GENQ  matrix. 

Real  square  matrix  with  the  number  of  rows  and  columns  equal  to  the  number  of 
rigid  body  modes  in  the  blast  analysis. 

MAPOL 
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Entity: 

Entity: 

Dexcription: 
Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0 

Element  identification  number 

PID 

Integer  >  0 

Element  property  identification  number 

PTYPE 

Tsxt  (8) 

Element  property  type 

LAYRNUM 

Integer  2:  0 

Composite  layer  number 

2IL1 

Integer  >  0 

Internal  grid  point  id  1 

SI.j2 

Integer  >  0 

Internal  grid  point  id  2 

SI  ^3 

Integer  >  0 

Internal  grid  point  id  3 

SIL4 

Integer  >  0 

Internal  grid  point  id  4 

THICK1 

Real  >  0.0 

Membrane  thickness  for  grid  1 

THICK2 

Real  >  0.0 

Membrane  thickness  for  grid  2 

THICK3 

Real  >  0.0 

Membrane  thickness  for  grid  3 

THICK4 

Real  >  0.0 

Membrane  thickness  for  grid  4 

CID1 

Integer  2  0 

Coordinate  system  defining  material  axis 

THETAM 

Real 

Material  orientation  angle 

OFFSTO 

Real 

Offset  of  the  element  reference  plane  from  the 
plane  of  grid  points. 

MIDI 

Integer  2  0 

Material  identification  number  for  membrane 

THICK 

Real  >  0.0 

Membrane  thickness 

MID2 

Integer  2  0 

Material  identification  number  for  bending 

BENDSTIF 

Real  >  0.0 

Bending  stiffness  parameter 

MID3 

Integer  2  0 

Material  identification  number  for  transverse 
shear 

TRNSVRS 

Real  >  0.0 

Transverse  shear  thickness  factor 

NSM 

Real  >  0.0 

nonstructural  man 

FZ1 

Real  >  0.0 

Fiber  distance  for  stress  computation 

FZ2 

Real  >  0.0 

Fiber  distance  for  stress  computation 

MID4 

Integer  >  0 

Material  identification  number  for  membrane¬ 
bending  coupling 

CIDS 

Integer  >  0 

Coordinate  system  defining  stress  output 
coordinate  system 

THETAS 

Real 

Stress  output  orientation  angle 

COORD1 

Integer 

External  coord  system  for  3IL1 

XI,  Yl,  Z1 

Real 

Basic  coordinates  of  SIL1 

QUAD4EST 

Relation 

Contains  the  element  summary  data  for  the  quadrilateral  QUAD4  plate  element. 
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Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


NAME 

TYPE/KEY 

DESCRIPTION 

COORD2 

Integer  >  0 

External  coord  system  for  SIL2 

X2 ,  Y2 ,  Z2 

Real 

Basic  coordinates  of  SIL2 

COORD3 

Integer  >  0 

External  coord  system  for  SIL3 

X3,  Y3,  Z3 

Real 

Basic  coordinates  of  SIL3 

COORD4 

Integer  >  0 

External  coord  system  for  SIL4 

X4 ,  Y4 ,  Z4 

Real 

Basic  coordinates  of  SIL4 

SCON 

Integer 

Stress  constraint  flag 

DESIGN 

Integer 

Design  flag 

STHRM 

Real  Array(3) 

Thermal  stress  terms  for  the  constrained 
element 

STHRMA 

Real  Array(3) 

Thermal  strain  terms  for  the  constrained 
element 

TREFPT 

Integer  >  0 

Pointer  to  the  TREE  entity  for  thermal 
Ioads/stress  evaluation  of  the  designed  element 

Module  MAKEST 

This  relation  is  built  from  the  CQUAD4,  associated  P  type  and  the  basic  grid 
point  data.  It  contains  one  tuple  for  each  isoparametric  QUAD4  element  in  the 
problem. 

RAND  PS 
Relation 

Contains  the  definition  of  load  set  power  spectral  density  factors  for  use  in  Ran¬ 
dom  analysis  having  the  frequency  dependent  form. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Random  analysis  set  identification  number 

EXCITID 

Integer  >  0 

Subcase  identification  number  of  excited 
load  set 

APPLYID 

Integer  >  0 

Subcase  identification  number  of  applied 
load  set 

X,  Y 

Real 

Components  of  complex  number 

TABRNDID 

Integer  >  0 

Identification  number  of  a  TABRNDi  entry 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


REAR 

Relation 

Contains  the  definition  of  a  rigid  bar  element  with  six  degrees  of  freedom  at  each 
end. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

MPC  identification  number 

EID 

Integer  >  0 

Rigid  bar  element  identification  number 

GA,  GB 

Integer  >  0 

Grid  point  identification  numbers  of 
connection  points. 

CNA, CNB 

Integer 

Independent  DOF  in  the  global  coordinate 
system  for  the  elements  at  grid  point  GA 
and  GB. 

CMA, CMB 

Integer 

Dependent  DOF  in  the  global  coordinate 
system  assigned  by  the  element  at  grid 
point  GA  and  GB 

Module  IFP 

RBE1 

Relation 

Contains  the  definition  of  a  rigid  body  connected  to  an  arbitrary  number  of  grid 
points. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

MPC  identification  number 

EID 

Integer  >  0 

Rigid  body  element  identification  number 

GXI 

Integer  >  0 

Grid  point  identification  numbers  at  which 
dependent/independent  DOF  are  assigned 

CXI 

Integer  >  0 

Component  numbers  of 
dependent/independent  DOF  in  the  global 
coordinate  system  at  grid  points  GXi 

UMFLAG 

Tfext  (4) 

Character  string  indicating  the  start  of  the 
list  of  dependent  degrees-of-freedom 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


RBE2 

Relation 

Contains  the  definition  of  a  rigid  body  whose  independent  degrees-of-freedom  are 
specified  at  a  single  grid  point  and  whose  dependent  degrees-of-freedom  are  speci¬ 
fied  at  an  arbitrary  number  of  grid  points. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

MPC  identification  number 

EID 

Integer  >  0 

Rigid  body  element  identification  number 

GN 

Integer  >  0 

Grid  point  identification  number  at  which 
all  six  independent  DOF  are  assigned 

CM 

Integer 

Component  numbers  of  dependent  degrees- 
of-freedom  in  the  global  coordinate  system 
assigned  by  the  element  at  grid  points  GMi 

GMI 

Integer  >  0 

Grid  point  identification  number  at  which 
dependent  DOF  are  assigned 

Module  IFP 

RBE3 

Relation 

Contains  the  definition  of  the  motion  of  a  reference  grid  point  as  the  weighted  av 
erage  of  motions  at  a  set  of  other  grid  points. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

MPC  identification  number 

EID 

Integer  >  0 

Rigid  body  element  identification  number 

REFGRID 

Integer  >  0 

Reference  grid  point  identification  number 

REFC 

Integer 

Component  numbers  of  DOF  in  the  global 
coordinate  system  that  will  be  computed  at 
REFGRID 

QI 

Integer 

Integer  field  of  either  grid  point  ID  or 
component  number 

QR 

Real 

Real  field  of  weighting  factor 

UMFLAG 

Tsxt  (4) 

Character  string  indicating  the  start  of  the 
list  of  dependent  DOF 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


RHS 

Subscripted  Matrix 

A  matrix  used  in  the  analysis  of  free-free  structures  that  corresponds  to  load  vec¬ 
tors  applied  to  the  supported  degrees  of  freedom. 

The  number  of  rows  is  equal  to  the  number  of  degrees  of  freedom  in  the  r-set 
while  the  number  of  columns  varies  by  the  type  of  analysis  being  performed. 

MAPOL 

1.  For  an  inertia  relief  analysis,  RHS  is  equal  to  PR  plus  the  transpose  of  D 
times  PLBAR. 

2.  For  a  static  aeroelastic  analysis,  RHS  is  equal  to  P2  minus  K21  times  PAR. 

3.  Since  RHS  may  be  needed  in  the  sensitivity  analysis,  it  is  subscripted  by 
boundary  condition  number. 

RLQAD1 

Relation 

Contains  information  on  frequency  dependent  loads  as  defined  in  the  RLOAD1 
bulk  data  entry. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer  >  0 

Set  identification  number 

I  LAG 

Integer 

Identification  number  for  DLAGS 

ITC 

Integer 

Identification  number  for  TABLEDi(C) 

ITD 

Integer 

Identification  number  for  TABLEDi(D) 

Module  IFP 


1.  The  relation  is  used  in  FRLGA  to  generate  dynamic  loads. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


RLQAD2 

Relation 

Contains  information  to  define  frequency  dependent  dynamic  loads  in  a  form 
specified  in  the  RLOAD2  bulk  data  entry. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer  >  0 

Set  identification  number 

I  LAG 

Integer 

Identification  number  for  DLAGS 

TB 

Integer 

Identification  number  for  TABLEDi(B) 

TP 

Integer 

Identification  number  for  TABLEDi(P) 

Module  IFP 
Notes: 

1.  The  relation  is  used  in  FRLGA  to  generate  dynamic  loads. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


RODE ST 
Relation 

Contains  the  element  summary  data  for  the  ROD  element. 


|  NAME 

1“ - “““1 

TYPE/KEY 

DESCRIPTION 

|  EID 

Integer  >  0,  key 

Element  identification  number 

PiD 

Integer  >  0 

Element  property  identification  number 

SIL1 

Integer  >  0 

Internal  id  of  grid  at  end  A 

SIL2 

Integer  >  0 

Internal  id  of  grid  at  end  B 

MIDI 

Integer  >  0 

Material  id  of  a  MAT1  tuple 

AREA 

Real  £  0.0 

Element  cross-sectional  area 

J 

Real  S  0.0 

Torsional  constant 

C 

Real 

Stress  recovery  coefficient 

NSM 

Real  2  0.0 

Element  nonstructural  mass 

COORD1 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  end  A 

XI,  Yl,  21 

Real 

Basic  coordinates  at  end  A 

COORD2 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  end  B 

X2,  Y2,  22 

Real 

Basic  coordinates  at  end  B 

SCON 

Integer 

Stress  constraint  flag 

DESIGN 

Integer 

Design  flag 

3THRM 

Real 

Thermal  stress  term  for  the  constrained 
element 

STHRMA 

Real 

Thermal  strain  term  for  the  constrained 
element 

TREFPT 

— ~~ _ 

Integer  >  0 

Pointer  to  TREE  entity  for  thermal  stress 
evaluation  and  thermal  loads  evaluation 

Module  MAKEST 


1.  This  relation  is  built  from  the  CONROD,  CROD,  PROD  and  basic  grid  point 
relations.  It  contains  one  tuple  for  each  ROD  element  in  the  problem. 

2.  A  nonzero  SCON  flag  denotes  that  the  element  is  affected  by  a  stress  con¬ 
straint. 

3.  A  nonzero  DESIGN  flag  denotes  that  the  element  is  affected  by  a  design  vari¬ 
able. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 


RROD 

Relation 

Contains  the  definition  of  a  pin-ended  rod  that  is  rigid  in  extension. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

MFC  identification  number 

EID 

Integer  >  0 

Rigid  rod  element  identification  number 

GA,  GB 

Integer  >  0 

Grid  point  identification  numbers  of 
connection  points. 

CMA, CMB 

Integer 

Component  number  of  one  dependent  DOF 
in  the  global  coordinate  system  assigned  by 
the  element  at  either  grid  point  GA  or  GB 

Module  IFF 


Entity: 
Entity  Type: 
Description: 

Matrix  Form. 

Created  By: 
Notes: 


R21 

Subscripted  Matrix 

Intermediate  matrix  formed  in  the  solution  of  structures  that  contain  unre¬ 
strained  degrees  of  freedom. 

Real  rectangular  matrix  with  one  row  for  each  r-set  degree  of  freedom  and  one  col¬ 
umn  for  each  a-set  degree  of  freedom. 

MAPOL 

1.  R21  is  the  transpose  of  IFR. 


Entity: 

Entity  Type: 
Description: 

Matrix  Form: 
Created  By: 
Notes: 


R22 

Matrix 

Intermediate  matrix  formed  in  the  solution  of  structures  that  contain  unre¬ 
strained  degrees  of  freedom. 

Real  square  matrix  with  one  row  and  solumn  for  each  r-set  degree  of  freedom. 
MAPOL 

1.  R22  is  created  from: 

[  R22  ]  =  [D  }T  *  [KIR  ]  +  [MRREAR  ] 
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Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 
Matrix  Form: 
Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


R31 

Subscripted  Matrix 

Intermediate  matrix  fo  med  m  the  solution  of  static  aeroelasitc  response. 

Real  rectangular  matrix  with  one  row  and  column  for  each  r-set  degree  of  free¬ 
dom  and  one  column  for  each  1-set  degree  of  freedom. 

MAPOL 

1.  R31  is  only  computed  for  the  steady  aeroelastic  analysis. 

2.  R31  is  created  from: 

[  H31  ]  =  [ZJ  ]T  *  [KMjL  ]  +  [rajRi  ] 

R32 

Subscripted  Matrix 

Intermediate  matrix  formed  in  the  solution  of  static  aeroelasitc  response. 

Real  square  matrix  with  one  row  and  column  for  each  r-set  degree  of  freedom. 
MAPOL 

1.  R32  is  only  computed  for  the  steady  aeroelastic  analysis. 

1.  R32  is  created  from: 

[  H32  ]  =  [D  ]r  *  [KALR  ]  +  [KSKR  ] 

SAVE 

Relation 

Contains  a  list  of  data  base  entities  whose  contents  are  to  be  saved  rather  then 
purged  through  the  UTPURG  utility. 


NAME 

TYPE/KEY 

DESCRIPTION 

ENTNAM 

Tfext  (8) 

The  name  of  a  database  entity. 

Module  IFF 


1.  An  entity  named  in  this  relation  will  not  have  its  contents  purged  by  the  UT¬ 
PURG  utility. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


SEQGP 
Relation  ' 

Contains  the  user  selected  resenquencing  requests  for  the  grid  and  scalar  points 
of  the  structural  modes. 


NAME 

TYPE/KEY 

DESCRIPTION 

EXTID 

Integer  >  0 

Grid  point  identification  number 

SEQNUM 

Text (8) 

Sequenced  identification  number  (see  beolw) 

Module  IFP 

1.  EXTID  is  any  grid  or  scalar  point  identification  number  which  is  to  be  reiden¬ 
tified  for  sequencing  purposes.  The  sequence  number  is  a  special  number 
which  may  have  any  of  the  following  forms  where  X  is  a  decimal  integer  digit 
—  XXXX.X.X.X,  XXXX.X.X,  XXXX.X,  or  XXXX  where  any  of  the  leading  X’s 
may  be  omitted.  This  string  contains  no  imbedded  blanks.  The  leading  charac¬ 
ter  will  not  be  a  decimal  point. 

SET1 

Relation 

Contains  a  list  of  structural  grid  points  to  be  used  in  splining  loads  from  aerody¬ 
namic  points  to  structural  points  and  modes  to  be  omitted  from  flutter  analyses. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

GRIDI 

Integer  >  0 

Structural  grid  point  id 

Module  IFP 


1.  This  relation  contains  one  tuple  for  each  grid  point  in  each  set. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


SET2 

Relation 

Contains  the  definition  of  a  set  of  structural  grid  points  in  terms  of  aerodynamic 
elements.  The  set  will  be  used  to  spline  aero  loads  to  the  structure. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

SP1 

Real 

Lower  spanwise  division 

SP2 

Real 

Upper  spanwise  division 

CHI 

Real 

Lower  chordwise  division 

CH2 

Real 

Upper  chordwise  division 

ZMAX 

Real 

Z-coordinate  of  upper  surface 

ZMIN 

Real 

Z-coordinate  of  lower  surface 

Module  IFP 


1.  Tuples  of  this  relation  are  referenced  by  the  GRDSETID  attribute  of  the 
SPLINE  1  and  SPLINE2  relations. 

SHAPE 

Relation 

Contains  the  element  identification  numbers  and  weighting  factors  specified  on 
the  SHAPE  Bulk  Data  entry. 


NAME 

TYPE/KEY 

DESCRIPTION 

SHAPEID 

Integer 

Shape  identification  number 

ETYPE1 

Tfext  (8) 

Element  type 

EID1 

Integer 

Element  identification  number 

PREF 

Real 

Design  variable  linking  factor 

Module  IFP 


1. 


Allowable  ETYPE1  entries  are: 

-  CROD,  CONROD 

-  CSHEAR 

-  CQDMEM1 

-  CQUAD4 

-  CTRIA3 

-  CTRMEM 


CMASS1,  CMASS2 

CBAR 

CONM2 

CELAS1,  CELAS2 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 
Notes: 


SHEARS ST 
Relation 

Contains  the  element  summary  data  for  the  shear  panel. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

PID 

Integer  >  0 

Element  property  identification  number 

SIL1 

Integer  >  0 

Internal  grid  point  id 

SIL2 

Integer  >  0 

SIL3 

Integer  >  0 

SIL4 

Integer  >  0 

MIDI 

Integer  >  0 

Material  id  of  a  MAT1  tuple 

THICK 

Real  >  0.0 

Element  thickness 

NSM 

Real  >  0.0 

Element  nonstructural  mass 

COORD 1 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  SIL1 

XI,  Yl,  Z1 

Real 

Basic  coordinates  of  SIL1 

COORD2 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  SIL2 

X2,  Y2,  Z2 

Real 

Basic  coordinates  of  SIL2 

COORD3 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  SIL3 

X3,  Y3,  Z3 

Real 

Basic  coordinates  of  SIL3 

COORD4 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  SIL4 

X4 ,  Y4 ,  Z4 

Real 

Basic  coordinates  of  SIL4 

SCON 

Integer 

Stress  constrain  flag 

DESIGN 

Integer 

Design  flag 

Module  MAKEST 


1.  This  relation  is  built  from  the  CSHEAR,  associated  P-type  and  the  basic  grid 
point  relations.  It  contains  one  tuple  for  each  shear  panel  in  the  problem. 

2.  A  nonzero  SCON  flag  denotes  that  the  element  is  affected  by  a  stress  con¬ 
straint. 

3.  A  nonzero  DESIGN  flag  denotes  that  the  element  is  affected  by  a  design  vari¬ 
able. 
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Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


SKJ 

Matrix 

Unsteady  aerodynamic  integration  matrix  list  that  translates  pressures  into 
forces  and  moments. 

Real  rectangular  matrix  with  one  row  for  each  .  rodynamic  degree  of  freedom 
and  one  column  for  each  aerodynamic  panel  for  each  M-k  pair. 

Module  UNSTEADY 

SLPMOD 

Matrix 

Intermediate  matrix  in  the  nuclear  blast  response  calculation  to  transform  elastic 
eigenvectors  into  slopes  at  aerodynamic  panel  control  points. 

Real  rectangular  matrix  with  one  row  for  each  aerodynamic  panel  and  one  col¬ 
umn  for  each  elastic  eigenvector. 

MAPOL 

SMAT 

Matrix 

Contains  the  sensitivity  of  the  stress  and  strain  in  the  elements  coordinate  sys¬ 
tem  to  the  global  displacements. 

A  variable-sized  double  precision  matrix  having  one  column  for  every 
stress/strain  term  in  each  element  that  is  constrained  by  a  stress/strain  con¬ 
straint  tuple  and  one  row  for  every  structural  degree  of  freedom.  The  columns  are 
stored  in  the  order  the  constrained  elements  are  processed  in  EMG. 

Module  EMG 

1.  This  matrix  is  not  built  if  no  elements’  stresses  or  strains  are  constrained. 

2.  SMAT  is  used  by  SCEVAL  module  for  constraint  evaluation  and  MAKDFU 
for  sensitivity  evaluation. 
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Entity: 

Entity  'Type: 
Description: 
Entity  Structure: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


SMPLQD 

Unstructured 

Simple  load  vector  information. 

Record  1  contains  three  integers  defining  the  number  of  (1) 
simple  external  loads,  NEXTLD,  (2)  gravity  loads,  NGRAV, 
and  (3)  thermal  loads,  NTHERM,  followed  by  a  list  of  load 
identification  numbers  for  each  of  the  three  groups  in  sorted 
order  within  each  group. 

The  seeond  through  NEXTLD  +  1  records  contain  the  exter¬ 
nal  loads. 

Module  LODGEN 

SPC 

Relation 

Contains  the  definition  of  the  single  point  constraints  and  enforced  displacements 
as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

GRID! 

Integer  >  0 

Grid  or  scalar  point  id 

CCMPNTSi 

Integer  >  0 

Components  of  GRID1  that  are  constrained 

ENFDISP 

Real 

The  value  of  the  enforced  displacement  at  all 
coordinates  specified  by  COMPNTS1 

Module  IFF 


1-  This  relation  is  used  by  the  MKUSET  module  to  build  the  single-point  con¬ 
straint  set. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


Entity: 

Entity  type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


SPC1 

Relation 

Contains  the  definition  of  the  single  point  constraints  as  input  from  the  Bulk 
Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

COMPNTS 

Integer  >  0 

Components  to  be  constrained 

GRIDI 

Integer  >  0 

Grid  point  id  defining  the  constrained 
components 

Module  EFP 

1.  This  relation  is  used  by  the  MKUSET  module  to  build  the  single-point  con¬ 
straint  set. 

2.  This  relation  will  contain  one  tuple  for  each  grid  point  specified  in  each 
unique  set  of  COMPNTS;  for  example, 

COMPNTS  =  236,  grids  5,6,  8  and  9 

and 

COMPNTS  =  134,  grids  10, 20 
will  result  in  6  tuples. 

SPCADD 

Relation 

Contains  the  definition  as  input  from  the  Bulk  Data  file  of  a  single-point  con¬ 
straint  sets  as  a  union  of  SPC  and/or  of  SPC1  sets. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

SPCSETID 

Integer  >  0 

Set  id  of  a  SPC  or  SPC1  tuple 

Module  IFP 

1.  This  relation  is  used  by  the  MKUSET  module  to  build  the  single-point,  con¬ 
straint  set. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


SPLINE 1 
Relation 

Contains  the  definition  of  surface  splines  used  for  interpolating  out-of-plane  mo¬ 
tion  in  aeroelastic  analysis. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

CP 

Integer  >  0 

Coordinate  system  defining  the  plane  of 
the  spline 

CAEROID 

Integer  >  0 

Aero  element  id 

BOX1 

Integer  >  0 

First  aero  box  to  use  the  spline 

BOX  2 

Integer  >  0 

Last  aero  box  to  use  the  spline 

GRDSETID 

Integer  >  0 

Set  id  of  a  SETi  tuple  defining  the 
structural  grids 

FLEX 

Real 

Linear  attachment  flexibility 

Module  IF? 


1.  Aerodynamic  boxes  are  numbered  sequentially  in  chordwise  strips. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


SPLINE2 

Relation 

Contains  the  definition  of  a  beam  spline  for  interpolating  panels  and  bodies  for 
steady  and  unsteady  aeroelastic  analysis. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0 

Element  identification  number 

MACROID 

Integer  >  0 

The  identification  of  the  aerodynamic 
macroelement  to  be  splined 

BOX1, BOX2 

Integer  >  0 

The  identification  numbers  of  the  first  and 
last  boxes  on  the  macroelement  to  be 
interpolated  using  this  spline 

GRDSETID 

Integer  >  0 

The  identification  of  a  SETi  entry  which 
lists  the  structural  grid  points  to  which  the 
spline  is  attached 

FLEX 

Real  >  0.0 

Linear  attachment  flexibility 

DTOR 

Real  £  0.0 

Torsional  flexibility 

CID 

Integer 

Rectangular  coordinate  system  which 
defines  the  y-axis  of  the  spline 

DTHX, DTHY 

Real 

Rotational  attachment  flexibility  about  the 
x-axis  and  y-axis 

Module  IFP 

SPOINT 

Relation 

Contains  the  identification  numbers  of  those  points  to  be  used  as  scalar  points. 
Input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

EXT  ID 

Integer  >  0 

External  point  identification 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  3y: 
Notes: 


STABCF 

Relation 

Rigid  body  stability  coefficients. 


NAME 

TYPE/KEY 

DESCRIPTION 

MACHINDX 

Integer 

Mach  number  index  of  associated  AIRFRC 

PARM 

String(8) 

Character  string  identifying  the  configuration 
parameter. 

SYMFLG 

Integer 

Symmetry  flag  for  the  parameter. 

PARMVAL 

Real 

Parameter  value  used  to  generate  the  "unit" 
forces.  ] 

CL 

Real 

Lift  coefficient  \ 

CD 

Real 

Drag  coefficient 

CS 

Real 

Sideforce  coefficient 

CMX 

Real 

Rolling  moment  coefficient 

CMY 

Real 

Pitching  moment  coefficient 

CMZ 

Real 

Yawing  moment  coefficient 

Module  STEADY 

1.  The  SYMFLG  values  are: 

=  1  Symmetric 

=  -1  Antisymmetric 

2.  PAEM  identifies  the  physical  variable  whose  perturbation  generated  the  rigid 
coefficients.  There  are  six  accelerations  and  six  configuration  parameters 
whose  names  are  reserved  that  have  special  meaning.  Additional  PABM  val¬ 
ues  come  from  the  set  of  all  AESURF  control  surfaces  defined  and  the  FARM 
attribute  contains  the  user  supplied  label.  For  a  given  MINDEX  value,  the 
AIRFRC  matrix  has  one  column  (which  may  contain  only  zeros)  for  each  en- 
try  in  STABCF  in  the  order  of  the  STABCF  relation.  The  PARM  field  is  then: 


PARM 

VARIABLE 

NX 

Rigid  body  acceleration  in  drag/thrust  dire  "Mon  (Produces  no 
forces,  but  included  for  completeness  to  allow  modification  of 
AIRFRC  columns  to  include  nonzero  terms) 

NY 

Rigid  body  acceleration  in  side  force  direction  (Produces  no  forces, 
but  included  for  completeness  to  allow  modification  of  AIRFRC 
columns  to  include  nonzero  terms)  | 
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PARM 

VARIABLE 

NZ 

Rigid  body  acceleration  in  plunge  direction  (Produces  no  forces,  but 
included  for  completeness  to  allow  modification  of  AIRFRC  columns 
to  include  nonzero  terms) 

PACCEL 

Rigid  body  acceleration  about  the  roll  axis.  (Produces  no  forces,  but 
included  for  completeness  to  allow  modification  of  AIRFRC  columns 
to  include  nonzero  terms) 

QACCEL 

Rigid  body  acceleration  about  the  pitch  axis.  (Produces  no  forces, 
but  included  for  completeness  to  allow  modification  of  AIRFRC 
columns  to  include  nonzero  terms) 

RACCEL 

Rigid  body  acceleration  about  the  yaw  axis.  (Produces  no  forces,  but 
included  for  completeness  to  allow  modification  of  AIRFRC  columns 
to  include  nonzero  terms) 

THKCAM 

Forces  arising  from  the  effects  of  only  thickness  and  camber  with 
all  other  configuration  parameters  set  to  zero. 

ALPHA 

Forces  arising  due  to  unit  angle  of  attack. 

BETA 

Forces  arising  due  to  a  unit  yaw  angle. 

|  PRATE 

Forces  arising  due  to  a  unit  roll  rate. 

i 

QRATE 

Forces  arising  due  to  a  unit  pitch  rate. 

RRATE 

Forces  arising  due  to  a  unit  yaw  rate 

surface 

Forces  arising  due  to  the  unit  deflection  of  the  AESURF  control 
surface  named  in  the  PARM  field. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 

Notes: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


SUPORT 

Relation 

Contains  the  definition  of  the  set  of  points,  as  input  from  the  Bulk  Data  file,  at 
which  the  user  desires  determinate  reactions  to  be  applied  to  a  free  body. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

GRID1 

Integer  >  0 

Grid  or  scalar  point  identification 

COMPNTS1 

Integer  £  0 

Components  of  GRID1 

Module  IFP 

1.  This  relation  will  be  used  by  the  MKUSET  relation  to  build  the  support  set. 

TABDMP1 

Relation 

Contains  modal  structural  damping  tables  for  use  in  flutter  analysis  as  input 
from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Set  identification  number 

TYPE 

Text (4) 

Damping  type 

FI 

Real  >  0.0 

Frequency  value 

FBCD 

Tbxt  (4) 

A  character  attribute  to  process  SKIP  requests 

GI 

Real 

Damping  value 

GBCD 

Text (4) 

A  character  attribute  to  process  SKIP  requests 

Module  IFP 
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Entity. 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 

Entity  Structure: 
Record: 

Created  By:. 
Notes: 


TABLED 1 
Relation 

Contains  tabular  function  data  for  generating  dynamic  loads  as  input  from  the 
Bulk  Data  file. 


I  NAME 

TYPE/KEY 

DESCRIPTION 

TID 

Integer 

Table  identification  number 

XI 

Real 

Time  (or  frequency)  for  the  tuple 

YI 

Reai 

Response  for  this  tuple 

STRXF 

Ttext  (4) 

A  character  attribute  to  process  skip  requests 

STRY1 

Tfext  (4) 

A  character  attribute  to  process  skip  requests 

IFP 


1.  The  relation  is  used  in  subroutine  PRTAB1  to  define  time  or  frequency  de¬ 
pendent  load. 

TELM 

Unstructured 

Contains  the  geometric  and  material  element  thermal  loads  partitions  if  any  ther¬ 
mal  loads  have  been  defined  in  the  model. 


i.  Each  record  contains  the  geometric  and  materia)  thermal  loads  partitions  for 
each  element  in  the  model  if  any  thermal  loads  have  been  defined  in  the 
model. 

Module  EMG 

1.  This  entity  contains  one  record  for  each  partition  of  each  element  thermal 
loads  matrix.  A  partition  is  that  portion  of  the  matrix  connected  to  one  pivot 
sil. 

2.  Refer  to  the  DVCT  relation  documentation  for  further  details. 

3.  The  TELM  terms  are  stored  in  the  same  precision  as  the  PG  matrix. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 

Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 


TEMP 

Relation 

Contains  the  grid  point  temperatures  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer 

The  set  identification  number 

GRID1 

Integer 

The  grid  point  id 

TEMPVAL 

Real 

The  valu6  of  temperature  assigned  to  GRID1 

Module  IFP 

TEMPD 

Relation 

Contains  the  default  grid  point  temperature  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer 

The  set  identification 

TEMPDVAL 

Real 

-  ...  ... 

The  default  grid  point  temperature  for  the  set 
SETID 

Module  IFP 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


Created  By: 


TF 

Relation 

Contains  the  definition  of  transfer  functions  as  input  from  the  Bulk  Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer 

Set  identification  number 

GD 

Integer 

Grid,  scalar  or  extra  point  id 

CD 

Integer 

Component  number  of  grid  point  GD 

BO 

Real 

Zeroth  order  coefficient 

B1 

Real 

First  order  coefficient 

B2 

Real 

Second  order  coefficient 

GI 

Integer 

Grid,  scalar  or  extra  point  id 

Cl 

Integer 

Component  number  of  grid  point  GI 

AO  I 

Real 

Zeroth  order  coefficient 

All 

Real 

First  order  coefficient 

lAZI 

Real  j  Second  order  coefficient 

Module  IFP 
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Entity:  TFDATA 

Entity  Type:  Unstructured 

Description:  Contains  the  collected  transfer  function  data  for  all  transfer  function  sets  defined. 

Entity  Structure: 

Record: 


1.  A  list  of  all  set  identification  numbers  in  sorted  order 
i.  Contains  the  transfer  function  for  the  (i-l)th  transfer  function  set.  Each  re¬ 
cord  has  the  following  form: 


WORD 

VARIABLE 

DESCRIPTION 

1 

SID 

Set  identification  for  the  (i-l)th  transfer  function 
set 

j 

COL 

Internal  number  of  the  matrix  column  affected  by 
the  transfer  function 

j+1 

NROW 

Number  of  terms  defined  in  the  column  COL 

j+2  to 

j+l+4*NHOW 

For  each  term  in  the  column  four  words  are  stored: 

1)  Internal  number  of  the  matrix  row 

2)  Oth  order  coefficient 

3)  1st  order  coefficient 

4)  2nd  order  coefficient 
in  sorted  row  order 

Created  By:  PFBULK 

Notes: 

1.  This  entity  is  used  in  DMA  to  assemble  dynamic  matrices. 

2.  The  j  index  runs  from  1  to  NCOL  for  each  column  in  the  matrix  that  is  af¬ 
fected  by  the  transfer  function  terms  in  sorted  column  order. 
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Entity: 


Entity  Type: 
Description: 

Relation  Attributes: 


TFIXED 

Relation 

Contains  the  layer  thicknesses  of  undesigned  layers  of  designed  composite  ele¬ 
ments. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0 

Element  identification  number 

ETYPE 

Tfext  (8) 

Element  type.  One  of  the  following: 

QDMEM1  QUAD4 

TRMEM  TRIA3 

LAYRNUM 

Integer  >  0 

Layer  number 

T 

Real  >  0.0 

Thickness 

Created  By:  MAKEST 

Notes: 

1.  These  thicknesses  are  used  in  the  evalation  of  thickness  constraints  and  com 
posite  laminate  constraints. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 

Created  By: 

Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 


TIMELIST 

Relation 

Contains  the  list  of  times  for  which  outputs  are  requested  as  input  from  the  Bulk 
Data  file. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer 

Set  identification  number 

TIME 

Real 

Time  value  in  consistent  units 

Module  IFP 

TLQAD1 

Relation 

Contains  information  on  time  dependent  loads  as  defined  on  the  TLOAD1  bulk 
data  entry. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer  >  0,  key 

Set  identification  number 

IDEL 

Integer  >  0 

ED  of  the  DLAGS  set 

TABL1 

Integer 

ID  of  the  TABLED  1  set 

Module  IFP 
Notes: 

1.  The  relation  is  used  in  module  OFPLOAD  to  generate  dynamic  loads. 
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Entity: 

Entity  Type: 
Description; 

Relation  Attributes: 


Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 


Created  By: 
Notes: 


TLQAD2 

Relation 

Contains  information  on  time  dependent  loads  as  defined  by  the  TLOAD2  bulk 
data  entry. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer  >  0,  key 

Set  identification  number 

IDEL 

Integer  >  0 

ED  of  the  DLAGS  set 

T1 

Real  £  0.0 

Time  constant 

T2 

Real  >  T 

Time  constant 

FREQ 

Real  >  0.0 

Frequency  parameter 

PHASE 

Real 

Phase  parameter 

CTEXP 

Real 

Exponential  coefficient 

GROWTH 

Real 

Growth  coefficient 

Module  IFP 


1.  The  relation  is  used  in  module  OFPLOAD  to  generate  dynamic  loads. 

TMN 

Subscripted  Matrix 

Contains  the  rigid  constraint  matrix  relating  the  displacements  at  dependent  de¬ 
grees  of  freedom  to  those  at  the  independent  degrees  of  freedom. 

A  variable-sized  single  precision  matrix  having  one  row  for  each  dependent  de¬ 
gree  of  freedom  and  one  column  for  each  independent  degree  of  freedom.  The 
rigid  constraint  matrix  is  built  from  MPC  and  rigid  elements  such  that: 

[ua  ]  =  [IMS'  ]  [Bn  ] 

Module  MKUSET 

1.  The  dimension  of  this  subscripted  matrix  must  be  large  enough  for  all  optimi¬ 
zation  and  analysis  boundary  conditions. 

2.  If  no  multipoint  constraints  are  defined,  this  matrix  will  have  no  columns. 
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Entity: 

TMP1 

Entity  Type: 

Matrix 

Description: 

A  scratch  matrix  used  at  various  points  in  the  MAPOL  sequence  for  intermediate 
calculation. 

Matrix  Form: 

Application  dependent. 

Created  By: 

MAPOL 

Entity: 

TMP2 

Entity  Type: 

Matrix 

Description: 

A  scratch  matrix  used  at  various  points  in  the  MAPOL  sequence  for  intermediate 
calculation. 

Matrix  Form: 

Application  dependent. 

Created  By: 

MAPOL 

Entity: 

TREF 

Entity  Type: 

Unstructured 

Description: 

Entity  Structure: 

Record: 

Contains  the  element  reference  temperature  for  each  element  in  the  model. 

1  Contains  the  reference  temperature  for  each  element  in  the  model.  The  tem¬ 
peratures  are  stored  in  the  order  the  elements  are  processed. 

Created  By: 

Notes: 

Module  EMG 

1.  Elements  are  processed  alphabetically  by  element  type  and  numerically 
within  each  element  type. 

2.  Entity  is  only  created  if  TEMP  or  TEMPD  bulk  data  entries  exist. 

3.  The  TREFPT  attribute  on  the  XXXEST  relations  points  to  the  position  in 
TREF  for  the  associated  reference  temperature. 
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Entity: 

Entity  Type: 
Description: 
Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

SETID 

Integer  >  0 

Trim  set  identification  number 

MACH 

Real  >  0.0 

Mach  number 

QDP 

Real  >  0.0 

Dynamic  pressure 

TRMTYP 

Ttext(8) 

Type  of  trim  desired 

EFFID 

Integer 

Identification  of  CONEFFS  bulk  data  entries 
which  modify  control  surface  effectiveness 
values 

VO 

Real 

Velocity 

LABELI 

Ttext(8) 

Label  defining  the  aerodynamic  trim 
parameters 

FREEI 

Tfext(4) 

Character  string  FREE 

FIXI 

Real 

Magnitude  of  the  trim  parameter 

MACHINDX 

Integer 

Mach  number  index  for  the  current  subcase 

SUBSCRPT 

Integer 

Subscript  counter 

SUBCASID 

Integer 

Subcase  identification  number 

TRIM 

Relation 

Contains  the  definition  of  a  trim  parameter  constraint. 


Created  By: 


Module  IFP  and  STEADY 


Entity: 

Entity: 

Dexcription: 
Relation  Attributes: 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0 

Element  identification  number 

PID 

Integer  >  0 

Element  property  identification  number 

PTYPE 

Ttext  (8) 

Element  property  type 

LAYRNUM 

Integer  >  0 

Composite  layer  number 

SIL1 

Integer  >  0 

Internal  grid  point  id  1 

SIL2 

Integer  >  0 

Internal  grid  point  id  2 

SIL3 

Integer  >  0 

Internal  grid  point  id  3 

THICK1 

Real  >  0.0 

Membrane  thickness  for  grid  1 

THICK2 

Real  >  0.0 

Membrane  thickness  for  grid  2 

THICK3 

Real  >  0.0 

Membrane  thickness  for  grid  3 

CID1 

Integer  >  0 

Coordinate  system  defining  material  axis 

THETAM 

Real 

Material  orientation  angle 

OFFSTO 

Real 

Offset  of  the  element  reference  plane  from  the 
plane  of  grid  points. 

MIDI 

Integer  >  0 

Material  identification  number  for  membrane 

THICK 

Real  >  0.0 

Membrane  thickness 

MID2 

Integer  >  0 

Material  identification  number  for  bending 

BENDSTIF 

Real  >  0.0 

Bending  stiffness  parameter 

MID3 

Integer  >  0 

Material  identification  number  for  transverse 
shear 

TRNSVRS 

Real  >  0.0 

Transverse  shear  thickness  factor 

NSM 

Real  >  0.0 

Nonstructural  mass 

FZ1 

Real  >  0.0 

Fiber  distance  for  stress  computation 

FZ2 

Real  >  0.0 

Fiber  distance  for  stress  computation 

MI  04 

Integer  >  0 

Material  identification  number  for  membrane¬ 
bending  coupling 

CIOS 

Integer  >  0 

Coordinate  system  defining  stress  output 
coordinate  system 

THETAS 

Real 

Stress  output  orientation  angle 

COORDl 

Integer 

External  coord  system  for  SIL1 

TRIA3EST 

Relation 

Contains  the  element  summary  data  for  the  triangular  TRIAS  element. 
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Created  By: 
Notes: 


NAME 

TYPE/KEY 

DESCRIPTION 

XI,  Yl,  Zl 

Real 

Basic  coordinates  of  SIL1 

COORD2 

Integer  >  0 

External  coord  system  for  SIL2 

X2,  Y2,  Z2 

Real 

Basic  coordinates  of  SIL2 

COORD3 

Integer  >  0 

External  coord  system  for  SIL3 

X3,  Y3,  Z3 

Real 

Basic  coordinates  of  SIL3 

SCON 

Integer 

Stress  constraint  flag 

DESIGN 

Integer 

Design  flag 

STHRM 

Real  Array(3) 

Thermal  stress  terms  for  the  constrained 
element 

STHRMA 

Real  Array(3) 

Thermal  strain  terms  for  the  constrained 
element 

TREFPT 

Integer  >  0 

Pointer  to  the  TREF  entity  for  thermal 
loads/stress  evaluation  of  the  designed  element 

Module  MAKEST 

This  relation  is  built  from  the  CTRIA3,  associated  P-type  and  the  basic  grid  point 
data.  It  contains  one  tuple  for  each  isoparametric  TRIA3  element  in  the  problem. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


TRMEMEST 

Relation 

Contains  the  element  summary  data  for  the  constant  strain  triangular  mem¬ 
brane  element. 


NAME 

TYPE/KEY 

DESCRIPTION 

EID 

Integer  >  0,  key 

Element  identification  number 

PID 

Integer  >  0 

Element  property  identification  number 

PTYPE 

Ttext(8) 

Element  property  type 

LAYRNUM 

Integer  >  0 

Composite  layer  number 

SIL1 

Integer  >  0 

Internal  grid  point  id 

SIL2 

Integer  >  0 

SIL3 

Integer  >  0 

CID 

Integer  >:  Q 

Coordinate  system  defining  material  axis 

THETA 

Real 

Material  orientation  angle  for  anisotropic 
material  behavior 

MIDI 

Integer  >  0 

Material  id  of  MAT1  tuple 

THICK 

Real  >  0.0 

Element  thickness 

NSM 

Real  5  0.0 

Element  nonstructural  mass 

COORD1 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  SIL1 

XI,  Yl,  Z1 

Real 

External  coordinate  system  id  for 
displacements  at  SILl 

COORD2 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  SIL2 

X2,  Y2,  Z2 

Real 

Extci  nal  coordinate  system  id  for 
displacements  at  SIL2 

COORD3 

Integer  >  0 

External  coordinate  system  id  for 
displacements  at  SIL3 

X3,  Y3,  Z3 

Real 

External  coordinate  system  id  for 
displacements  at  SIL3 

SCON 

Integer 

Stress  constraint  flag 

DESIGN 

Integer 

Design  flag 

STHRM 

Real  Array  (3) 

Thermal  stress  terms  for  the  constrained 
element 

STHRMA 

Real  Array  (3) 

Thermal  strain  terms  for  the  constrained 
element 
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NAME 

TYPE/KEY 

DESCRIPTION 

TREFPT 

Integer  >  0 

Pointer  to  TREF  entity  used  to  evaluate 
thermal  loads  and  thermal  stresses 

Created  By:  Module  MAKEST 

Notes: 

1.  This  relation  is  built  from  the  CTRMEM,  associated  P-type  and  the  basic  grid 
point  relations.  It  contains  one  tuple  for  each  triangular  membrane  element 
in  the  problem. 

2.  A  nonzero  SCON  flag  denotes  that  the  element  is  affected  by  a  stress  con¬ 
straint. 

3.  A  nonzero  DESIGN  flag  denotes  that  the  element  is  affected  by  a  design  vari¬ 
able. 

4.  LAYRNUM  is  zero  for  noncomposite  elements. 
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Entity: 

Entity  Type: 
Description: 

Relation  Attributes: 


Created  By: 
Notes: 


TSTEP 

Relation 

Contains  time  step  information  for  the  dynamic  response  as  input  from  the  Bulk 
Data  file. 


NAME 

TYFfc/KEY 

DESCRIPTION 

SID 

Integer  >  0 

Time  step  identification  number 

NDTI 

Integer  >  2 

Number  of  time  steps  for  this  tuple 

DELTAI 

Real  >  0.0 

Time  increment  for  this  tuple 

NOUTI 

Integer 

Skip  factor  for  this  tuple 

Module  EFP 

1.  The  response  at  every  NOUTIth  time  step  will  be  saved  for  output. 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


UA 

Matrix 

Displacements  in  the  a-set. 

A  variable-size  matrix  having  one  row  for  each  degree  of  freedom  in  the  analysis 
set  and  one  column  for  each  load  condition  in  the  current  boundary  condition. 

See  Notes. 

1.  This  matrix  is  calculated  using: 

[jai  ]  tot  ]  =  [Pi  l 

if  there  is  inertia  relief, 

[Da.  ]  =  [10.112  ]  [AH  ]  +  [PAR  ]  [EEiEA  ] 
for  static  aeroelasticity,  and 
[KRA  ]  [t&  ]  =  [PA  ] 

for  static  analysis  without  inertia  relief. 

2.  SeeUG. 
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Entity: 

UBLASTG 

Entity  Type: 

Matrix 

Description: 

Blast  response  quantities  in  the  g-set 

Matrix  Form: 

Real  rectangular  matrix  with  one  row  for  each  g-set  degree  of  freedom  and  three 
columns  (corresponding  to  displacement,  velocity,  and  acceleration)  for  each  time 
step  at  which  transient  calculations  are  retained. 

Created  By: 

MAPOL 

Entity: 

UBLASTI 

Entity  Type: 

Matrix 

Description: 

Blast  response  quantities  in  the  i-set. 

Matrix  Form: 

Real  rectangular  matrix  with  one  row  for  each  retained  mode  and  three  columns 
(corresponding  to  displacement,  velocity,  and  acceleration)  for  each  time  step  at 
which  transient  calculations  are  retained. 

Created  By: 

BLASTDRV 

Entity: 
Entity  Type: 
Description: 
Record: 


Created  By: 
Notes: 


Entity. 
Entity  Type: 
Description: 


UDLOLY 

Unstructured 

Contains  collected  DLONLY  information. 


1.  CD’s  of  the  NDIS  DLONLY  sets  in  sorted  order.  Contains  data  fey  the  (i-l)th 
DLONLY  set.  The  information  on  each  of  these  records  is: 


WORD  NO 

VARIABLE 

DESCRIPTION 

j 

LOAD 

Load  factor 

j+1 

ISIL 

Infernal  ED  of  load  component 

Module  PFBULK 

1.  The  number  of  words  for  the  ith  record  is  twice  the  number  of  load  factors  in¬ 
put  for  the  associated  set  ID. 


UF 

Matrix 

Displacements  in  the  f-set  derived  from  UO  and  UACsee  UG). 
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Entity: 

ufreqa 

Entity  Type: 

Matrix 

Description: 

Matrix  of  frequency  response  quantities  in  the  a-set. 

Matrix  Form: 

A  complex  rectangular  matrix  with  one  row  for  each  a-set  degree  of  freedom  and 
three  columns  (corresponding  to  displacement,  velocity,  and  acceleration)  for  each 
frequency  at  which  frequency  response  output  is  required. 

Created  By: 

Module  DYNRSP  or  MAPOL 

Notes: 

1.  If  the  direct  method  of  frequency  response  is  used,  UFREQ  is  computed  in 
module  DYNRSP.  If  the  modal  method  is  used,  UFREQAis  recovered  using 
UFREQI  and  PHIA. 

Entity: 

UFREQE 

Entity  Type: 

Matrix 

Description: 

Matrix  of  frequency  response  quantities  in  the  e-set. 

Matrix  Form: 

A  complex  rectangular  matrix  with  one  row  for  each  e-set  degree  of  freedom  and 
three  columns  (corresponding  to  displacement,  velocity,  and  acceleration)  for  each 
frequency  at  which  frequency  response  output  is  required. 

Created  By: 

Module  DYNRSP 

Notes: 

i.  UFREQE  is  only  computed  in  a  frequency  response  analysis  that  includes  ex¬ 
tra  points. 

Entity: 

UB'REQF 

Entity  Type: 

Matrix 

Description: 

Matrix  of  frequency  response  quantities  in  the  f-set. 

Matrix  Form: 

A  complex  rectangular  matrix  with  one  row  for  each  f-set  degree  of  freedom  and 
three  columns  (corresponding  to  displacement,  velocity,  and  acceleration)  fer  each 
frequency  at  which  frequency  response  output  is  required. 

Created  By: 

MAPOL 

Entity: 

UFREQG 

Entity  Type: 

Matrix 

Description: 

Matrix  of  frequency  response  quantities  in  the  g-set. 

Matrix  Form: 

A  complex  rectangular  matrix  with  one  row  for  each  g-set  degree  of  freedom  and 
three  columns  (corresponding  to  displacement,  velocity,  and  acceleration)  for  each 
frequency  at  which  frequercy  response  output  is  required. 

Created  By: 

MAPOL 

664 


Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 

Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


UFREQI 

Matrix 

Matrix  of  frequency  response  quantities  in  the  i-set 

A  complex  rectangular  matrix  with  one  row  for  each  i-set  degree  of  freedom  and 
three  columns  (corresponding  to  displacement,  velocity,  and  acceleration)  for  each 
frequency  at  which  frequency  response  output  is  required. 

Module  DYNRSP 

1.  This  matrix  is  only  computed  when  the  modal  method  of  frequency  response 
is  invoked. 

UFREQN 

Matrix 

Matrix  of  frequency  response  quantities  in  the  n-set. 

A  complex  rectangular  matrix  with  one  row  for  each  n-set  degree  of  freedom  and 
three  columns  (corresponding  to  displacement,  velocity,  and  acceleration)  for  each 
frequency  at  which  frequency  response  output  is  required. 

MAPOL 


UG 

Subscripted  Matrix 

Displacements  of  the  structural  degrees  of  freedom  in  the  g-set. 

A  variable-sized  matrix  haring  one  row  for  each  structural  degree  of  freedom  and 
one  column  for  each  load  condition  in  the  boundary  ondition. 

MAPOL 


1.  The  MAPOL  sequence  recovers  this  matrix  in  the  following  order  (see  the 
Theoretical  Manual  for  the  explicit  form  of  this  recovery): 


uo 

UA 

YS 

On 


DM 

UN 


->  UF 

->  UN 

->  UG 
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Entity: 

Entity  Type: 
Description: 
Matrix  Form: 
Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 

Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


UGA 

Matrix 

"Active"  displacements  vectors  for  the  current  boundary  condition. 

The  matrix  has  one  column  for  each  active  displacement  vector  and  GSIZE  rows. 
MAPOL 

1.  This  matrix  is  obtained  by  partitioning  UG  using  the  PGA  partitioning  vector. 

UGTKAB 

Matrix 

A  partition  of  the  UGTKF  matrix  (see  UGTKG). 

UGTKA. 

Matrix 

Unsteady  spline  matiix  in  the  a-set  derived  from  UGTKF  (see  UGTKG). 

UGTKF 

Matrix 

Unsteady  spline  matrix  in  the  f-set  derived  from  UGTKN  (see  UGTKG). 

UGTKG 

Matrix 

Matrix  containing  the  spline  relations  which  relate  the  structural  and  unsteady 
aerodynamics  models 

Real  rectangular  matrix  with  one  row  for  each  g-set  degree  of  freedom  and  one 
column  for  each  aerodynamic  degree  of  freedom. 

Module  SPLINEU 

1.  The  MAPOL  sequence  supports  the  following  partitions  of  the  UGTKG  ma¬ 
trix  (see  the  Theoretical  Manual  for  the  exact  formation  of  these  matricie3): 

9 

UGTKN 
9 

UGTKN 

9 

UGTKN 

[UGTKAB  ]  +  [GSOBO  f  [UGTKO  ] 


UGTKG 

UGTKG  -> 

UGTKG  -» 
[UGTKA  ]  = 
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Entity: 
Entity  Type: 
Description: 

Entity: 
Entity  Type: 
Description: 

Entity: 
Entity  Type: 
Description: 
Matrix  Form 

Created  by: 
Notes: 

Entity: 
Entity  Type: 
Description: 

Entity: 
Entity  Type: 
Description: 


UGTKN 

Matrix 

Unsteady  spline  matrix  in  the  n-set  derived  from  UGTKG  (see  UGTKG). 

UGTKO 

Matrix 

Unsteady  spline  matrix  in  the  o-set  obtained  as  a  partition  of  UGTKF  (see 
UGTKG). 

UKQ 

Matrix 

Upper  triangular  portion  of  the  decomposed  KEQE  matrix. 

Square  real  matrix  having  one  row  and  column  for  each  elastic  mode  retained  in 
the  nuclear  blast  response  analysis. 

DECOMP 

1.  KEQE  is  not  symmetric. 

2.  This  matrix  is  formed  for  use  by  the  GFBS  large  matrix  utility. 

UM 

Matrix 

Displacements  in  the  m-set  derived  from  UN  and  TMN  (see  UG). 


UN 

Matrix 

Displacements  in  the  n-set  derived  from  UF  and  YS  (see  UG). 
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UNMK 

Unstructured 


Entity: 

Entity  Type: 
Description: 

Entity  Structure: 


Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Contains  a  global  list  of  Mach  number  and  reduced  frequency  pairs  for  which 
aerodynamic  matrices  were  generated  in  the  aerodynamic  matrix  lists. 


RECORD 

WORDS 

DESCRIPTION 

1 

1-6 

A  one-word  entry  for  each  combination  of 
symmetry  options  in  the  order  noted  containing 
the  number  of  m-k  pairs  having  the  particular 
symmetry  option 

7-6+4*nmk 

Contains  one  four  word  entry  for  each  aerodynamic 
matrix  selected  for  generation  by  the  MKAEROi 
entries  of  the  following  form: 

M.  K.  SYMXZ.  SYMXY 

2 

1-2*3GRP 

Contains  the  number  of  j  degrees  of  freedom  and 
the  number  of  k  degrees  of  freedom  for  each 
unsteady  aerodynamic  croup 

Module  UNSTEADY 

1.  Record  1  is  sorted  first  by  Mach  number  (M)  and  then  by  reduced  frequency 
(k)  within  each  M  value  for  each  combination  of  symmetry  values.  The  sym¬ 
metry  options  are  treated  in  the  follow  ng  order: 


ORDER 

SYMXZ 

SYMXY 

1 

-1 

-1 

2 

-1 

0 

3 

0 

-1 

4 

0 

0 

5 

1 

-1 

6 

1 

0 

UO 

Matrix 

Sensitivities  of  displacements  in  th8  o-sst. 

Areal  rectangular  matrix  with  one  row  for  each  o-set  degree  of  freedom  and  one 
column  for  each  active  subcase  times  the  number  of  design  variables. 

MAFOL 

1.  For  static  aeroelastic  analysis,  UO  is  computed  from: 

[TO  ]  =  [GASUBO  J  *  [WAV  ]  +  [1700  ] 

2.  For  inertia  relief,  UO  is  computed  from: 

[TO  ]  =  [CSDBO  ]  *  [D0av  ]  +  [TOO  ] 
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Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 


Entity: 
Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 


UOO 

Matrix 

Intermediate  displacement  sensitivities  of  the  o-set. 

Areal  rectangular  matrix  with  one  row  for  each  o-set  degree  of  freedom  and  one 
column  for  each  active  subcase  times  the  number  of  design  variables. 

GFBS 

1.  UOO  is  computed  from: 

[2QOO  ]  [TOO  ]  =  | 'DBOV  +  PQ&RO  «■  VOELDV  J 

2.  For  inertia  relief,  UOO  is  computed  from: 

[xaoo  ]  [too  ]  =  [bpov  +  im  *  vm d  ] 

URDB 

Matrix 

Vector  of  aircraft  rigid  body  accelerations  that  are  computed  for  aircraft  trim 
prior  to  the  nuclear  blast  response  calculation. 

Real  rectangular  matrix  having  two  rows  (vertical  and  angular  acceleration)  and 
one  column. 

BLASTRIM 
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Entity: 
Entity  Type: 
Description: 


USET 

Unstructured 


Contains  the  bit  masks  defining  the  structural  sets  to  which  the  degress  of  free¬ 
dom  belong. 

Entity  Structure: 

Record: 

i  Each  record  contains  the  boundary  condition  id  as  the  first  word  followed  by 
one  word  for  each  dependent  set  containing  the  number  of  DOF  in  each  de¬ 
pendent  set.  These  are  followed  by  one  word  for  each  degree  of  freedom  con¬ 
taining  the  bit  masks  defining  the  structural  sets  to  which  they  belong. 

Created  By:  Module  MKUSET 

Notes: 

1.  This  entity  contains  one  record  for  each  boundary  condition  in  the  problem. 

2.  The  bit  masks  are  used  to  generate  matrix  partitioning  vectors. 

3.  The  11th  word  of  the  INFO  array  for  this  entity  contains  the  number  of  de¬ 
grees  of  freedom  in  the  structural  model  (g-  set  size). 

4.  The  USET  header  has  the  following  form: 

WORD  DESCRIPTION 

1  Boundary  condition  id 

2  Number  of  m-set  dofs 

3  Number  of  s-set  dofs 

4  Number  of  o-set  dofs 

5  Number  of  r-set  dofs 

Entity:  UTRANA 

Entity  Type:  Matrix 

Description:  Matrix  of  transient  response  quantities  in  the  a-set. 

Matrix  Form:  Complex  rectangular  matrix  with  one  row  for  each  a-set  degree  of  freedom  and 

three  columns  (corresponding  to  displacement,  velocity,  and  acceleration)  for  each 
time  step  at  which  transient  response  output  is  required. 

Created  By:  Module  DYNRSP  or  MAPOL 

Notes: 

1.  If  the  direct  method  of  transient  response  is  used,  UTRANA  is  computed  in 
module  DYNRSP.  If  the  modal  method  is  used,  UTRANA  is  recovered  using 
UTRANI  and  PHLA. 

Entity:  UTRANE 

Entity  Type:  Matrix 

Description:  Matrix  of  frequency  response  quantities  in  the  e-set. 

Matrix  Form:  Complex  rectangular  matrix  with  one  row  for  each  e-set  degree  of  freedom  and 

three  columns  (corresponding  to  displacement,  velocity,  and  acceleration)  for  each 
time  step  at  which  transient  response  output  is  required. 

Created  By:  Module  DYNRSP 
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Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 

Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 
Notes: 

Entity: 

Entity  Type: 
Description: 
Matrix  Form: 

Created  By: 


UTRANF 

Matrix 

Matrix  of  frequency  response  quantities  in  the  f-set. 

Complex  rectangular  matrix  with  one  row  for  each  f-set  degree  of  freedom  and 
three  columns  (corresponding  to  displacement,  velocity,  and  acceleration)  for  each 
time  step  at  which  transient  response  output  is  required. 

MAPOL 

UTRANG 

Matrix 

Matrix  of  frequency  response  quantities  in  the  g-set. 

Complex  rectangular  matrix  with  one  row  for  each  g-set  degree  of  freedom  and 
three  columns  (corresponding  to  displacement,  velocity,  and  acceleration)  for  each 
frequency  at  which  frequency  response  output  is  required. 

MAPOL 

UTRANI 

Matrix 

Matrix  of  frequency  response  quantities  in  the  i-set. 

Complex  rectangular  matrix  with  one  row  for  each  i-set  degree  of  freedom  and 
three  columns  (corresponding  to  displacement,  velocity,  and  acceleration)  for  each 
time  step  at  which  transient  response  output  is  required. 

Module  DYNRSP 

1.  This  matrix  is  only  computed  when  the  modal  method  of  transient  response 
analysis  is  invoked. 

UTRANN 

Matrix 

Matrix  of  frequency  response  quantities  in  the  n-set. 

Complex  rectangular  matrix  with  one  row  for  each  n-set  degree  of  freedom  and 
three  columns  (corresponding  to  displacement,  velocity,  and  acceleration)  for  each 
time  step  at  which  transient  response  output  is  required. 

MAPOL 
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Entity: 
Entity  Type: 
Description: 


VSDAMP 

Relation 


Relation  Attributes: 


Created  By: 
Notes: 


Entity: 

Entity  Type: 
Description: 

Matrix  Form: 

Created  By: 
Notes: 


Contains  the  specification  of  parameters  used  to  generate  viscous  damping  terms 
in  the  dynamic  matrices. 


NAME 

TYPE/KEY 

DESCRIPTION 

SID 

Integer 

Set  identification  number 

GVAL 

Real 

Damping  value 

OMEGA3 

Real 

Cyclic  frequency 

Module  1FP 

1.  If  both  GYAL  and  OMEGA3  are  nonzero,  equivalent  structural  damping  is 
used  to  generate  the  BDD  and/or  BHH  entities. 

2.  If  only  GVAL  is  nonzero,  structural  damping  is  used  for  direct  or  modal  fre¬ 
quency  or  flutter  analyses. 

YS 

Subscripted  Matrix 

Contains  the  column  vector  of  enforced  displacements  of  degrees  of  freedom  con¬ 
strained  by  single  point  constraints  (see  UG). 

A  variable-sized  single  precision  column  vector  having  one  row  for  each  single 

point  constraint  degree  of  freedom. 

Module  MKUSET 

1.  If  no  nonzero  enforced  displacements  are  specified  for  SPC’d  degrees  of  free¬ 
dom,  this  matrix  will  have  no  columns. 


10.  APPLICATION  PROGRAMMER  NOTES 


One  of  the  strengths  of  the  ASTROS  architecture  is  the  ease  with  which  the  system  can  be 
modified  and  enhanced.  Therefore,  many  ASTROS  users  will  find  it  convenient  and  useful  to  write 
software  to  perform  special  purpose  tasks  within  the  ASTROS  environment  rather  than  in  the  more 
typical  post-processing  style.  That  is,  instead  of  writing  the  ASTROS  results  to  an  intermediate  medium 
to  be  read  by  the  special  routine,  the  new  feature  will  be  installed  into  the  ASTROS  system.  The  intent  of 
this  section  is  to  give  this  type  of  ASTROS  programmer  an  overview  to  wilting  modules  that  interface 
with  the  ASTROS  system. 

Coding  standards  and  software  design  guidelines  are  given  to  create  a  module  that  functions 
within  the  ASTROS  architecture  without  creating  integration  problems.  Also,  informal  guidelines  to 
using  the  ASTROS  Dynamic  Memory  Manager  (DMM)  and  the  applications  interface  to  the  Computer 
Automated  Design  Database  (CADDB)  are  presented.  These  presentations  are  necessarily  limited  in 
scope  and  do  not  provide  a  comprehensive  guide  to  every  aspect  of  ASTROS  programming.  They  should, 
however,  be  sufficient  for  the  advanced  ASTROS  user  to  write  modules  to  perform  special  tasks  without 
(1)  duplicating  functions  that  already  exist  in  the  ASTROS  software  and  (2)  writing  code  that  causes 
errors  outside  the  module  being  written.  This  section  is  divided  into  four  subsections.  Subsection  10.1 
discusses  coding  standards  including  programming  language  and  modular  design.  Subsection  10.2  con¬ 
tains  suggestions  for  how  to  make  the  best  use  of  the  DMM,  while  subsection  10.3  is  concerned  with  the 
CADDB  features.  Finally,  Subsection  10.4  combines  these  topics  and  gives  guidelines  for  I/O  and  system 
level  interfaces  within  the  ASTROS  architecture. 
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10.1.  SOFTWARE  STANDARDS 


ASTROS  was  designed  to  be  machine  transportable,  maintainable,  and  easy  to  enhance.  To 
achieve  these  goals,  a  set  of  software  standards  was  defined  both  to  design  the  modules  and  to  guide  the 
codification  of  the  resulting  algorithms.  While  these  concepts  were  required  for  all  ASTROS  development 
efforts,  they  are  not  required  for  the  developer  of  a  new  ASTROS  module  that  is  outside  the  scope  of  the 
official  code.  Many  of  these  concepts,  however,  provide  useful  guidelines  for  all  code  development  and 
avoid  several  potential  pitfalls. 

The  most  crucial  concept  is  that  of  modularity.  From  the  programmer’s  point  of  view,  this  means 
that  the  mechanisms  by  which  the  module  communicates  with  other  modules  and  with  the  executive  are 
limited  to  maximize  the  independence  of  each  module.  For  example,  the  interdependence  of  modules  is 
reduced  by  communicating  with  data  structures  (e.g.,  relations,  matrices,  and  unstructured  entities)  that 
reside  on  the  database  rather  than  in  memory.  Further  independence  is  achieved  by  using  dummy 
arguments  to  communicate  between  program  units  within  a  module  and  by  avoiding  the  use  of  pathologi¬ 
cal  communications  such  as  common  blocks.  This  mechanism  of  internal  communication  is  well  suited  to 
the  DMM  for  reasons  of  both  modularity  and  simplicity.  The  DMM  also  eases  the  programmer’s  task  in 
ensuring  modularity  by  preventing  the  passage  between  modules  of  those  data  stored  in  open  core  blocks. 
The  programmer  is  also  given  some  additional  debugging  tools  to  ensure  that  the  modularity  has  been 
maintained. 

Modularity  and  maintainability  may  be  further  enhanced  by  recognizing  that  there  are  several 
distinct  groups  of  code  in  ASTROS.  These  are  the  system  level  modules,  the  engineering  application 
modules,  the  application  utility  modules,  the  large  matrix  utility  modules,  and  the  database/memory 
manager  utility  modules.  All  these  modules  comprising  the  current  system  are  documented  in  Sections  3 
through  8.  Most  important  from  the  application  programmer’s  point  of  view  are  the  utility  moc'ules.  The 
programmer  should  become  familiar  with  the  utility  modules  so  that  optimal  use  can  be  made  of  the 
existing  ASTROS  software.  By  using  the  existing  utilities  whenever  possible,  needless  duplication  of  code 
is  avoided  and  the  maintainability  is  enhanced.  Also,  the  ability  to  read  the  cede  is  improved  since  the 
limited  number  of  utilities  are  easily  recognized  by  another  programmer  and  no  time  need  be  spent  in 
determining  the  function  of  a  duplicate  code  block. 

Machine  transportability  was  a  major  consideration  in  the  development  of  the  ASTROS  system. 
This  requirement  is  not  as  critical  for  the  application  programmer  who  wants  to  install  a  special  purpose 
module  into  the  ASTROS  system.  It  may  be  useful,  however,  to  follow  some  basic  guidelines,  if  for  no 
other  reason  than  the  module’s  off-site  utility.  The  basic  guideline  to  follow  is  that  all  code  be  developed 
using  the  FORTRAN  language  adhering  to  the  ANSI  X3.9-1978  standard.  This  assures  proper  compila¬ 
tion  and  execution  over  a  wide  variety  of  computers  and  operating  systems.  Common  nonstandard 
features  such  as  certain  file  operations,  FORTRAN  enhancements  and  the  use  of  site  specific  utility 
libraries  should  be  avoided  to  maintain  the  transportability  of  the  resultant  system.  It  may  be  the  case 
that  the  enhanced  or  site  specific  features  are  required  in  the  new  module.  If  so,  the  transportability  of 
the  system  cannot  be  maintained:  the  programmer  should  give  serious  consideration  to  the  ramifications 
of  this  loss  before  committing  to  a  nonstandard  piece  of  code. 

In  the  author’s  experience,  the  most  common  problems  with  machine  dependencies  (aside  from 
those  already  isolated)  come  from  code  developed  using  nonstandard  FORTRAN  enhancements.  Often, 
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the  resident  FORTRAN  compiler  does  not  identify  extensions  to  the  standard  and  inexperienced  program¬ 
mers  do  not  recognize  that  their  code  is  nonstandard.  A  brief  list  of  enhancements  that  are  frequently 
seen  and  that  should  be  avoided  is: 


1.  The  use  of  hollerith  data  outside  DATA  statements  and  FORMAT  statements. 

2.  Special  OPEN  and  CLOSE  parameters  and  other  file  operations.  Unless  absolutely  necessary, 
I/O  should  be  limited  to  the  database  and  the  standard  output  file  or  punch  file. 

3.  DO-WHILE  and  DO-UNTIL  looping  constructs  —  these  can  and  should  be  emulated  using 
standard  FORTRAN. 

4.  Nonstandard  variable  names:  in  excess  of  6  characters  in  length  or  containing  nonstandard 
characters. 

5.  CHARACTER  and  non-CHARACTER  data  within  a  single  named  COMMON  block  —  many 
compilers  allow  this  without  warning  but  it  is  nonstandard  and  can  cause  problems. 

6.  Very  large  or  very  small  constants  often  create  problems  in  that  the  range  of  legal  real  numbers 
is  highly  machine  dependent. 

7.  Nonstandard  type  declarations:  common  examples  are  DOUBLE  PRECISION  COMPLEX, 
REAL*16,  and  INTEGER*!. 
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10.2.  OPEN  CORE  CONCEPTS  —  DMM 


ASTROS  has  a  powerful  and  flexible  Dynamic  Memory  Manager  (DMM)  which  allows  the  pro¬ 
grammer  to  allocate  blocks  of  memory  of  a  variable  size  determined  at  execution  time.  Various  groups  of 
memory,  each  containing  one  or  more  blocks,  may  be  allocated  and  assigned  names.  The  DMM  then 
returns  pointers  to  the  various  blocks  relative  to  a  single  named  common  block  unique  to  each  module 
All  but  the  smallest  local  arrays  used  within  a  subroutine  should  use  the  DMM.  There  are  three  major 
reasons  for  this:  (1)  it  eliminates  the  need  to  make  a  priori  judgements  about  the  size  of  arrays  to 
allocate,  thus  eliminating  or  reducing  the  problem  size  restrictions  (2)  the  DMM  can  automatically  take 
into  account  the  precision  of  the  data  and  (3)  the  resultant  code  is  more  likely  to  be  modular  since  the 
DMM  promotes  the  modular  use  of  memory  resources.  These  important  application  utilities  are  docu¬ 
mented  in  Section  3.3. 

Memory  can  be  allocated  or  released  at  any  point  in  the  code,  allowing  the  programmer  to  make 
optimal  use  of  system  resources.  Typically,  however,  memory  requests  are  made  in  high  level  routines 
within  a  module,  and  the  resultant  memory  block  addresses  are  passed  to  the  subroutines  which  make 
use  of  them.  In  this  manner,  the  lower  level  routines  may  be  coded  in  an  open-ended,  modular  fashion 
with  no  need  to  keep  track  of  memory  block  pointers.  This  approach  is  ideal  when  incorporating  other 
codes  (which  do  not  make  use  of  dynamic  memory  management)  into  the  ASTROS  system.  In  these  cases, 
a  top  level  driver  routine  for  the  new  module  may  isolate  all  requests  to  allocate  and  subsequently  free 
memory  used  within  the  module.  By  passing  the  starting  address  of  the  memory  block  to  the  lower  level 
routines,  the  original  array  variables  may  often  be  preserved  (thus  avoiding  extensive  recoding)  and  any 
fixed  dimensions  for  this  array  are  removed.  An  equally  effective  technique  is  to  pass  the  base  core 
address  (the  address  passed  to  the  MMBASE  utility)  to  the  lower  level  routines.  This  method  has  the 
added  benefit  of  eliminating  the  open  core  COMMON  block  from  the  lower  level  routines. 
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10.3.  CADDB  APPLICATION  INTERFACE 


CADDB  is  the  basis  of  the  majority  of  I/O  activity  within  ASTROS.  All  of  the  input  data, 
transitional  results  and  answers  are  placed  into  entities  on  this  ch-  tabe.'-.  Modules  and  subroutines  are 
free  to  draw  from  the  existing  entities  and  to  create  new  entities,  both  fot  arshivul  purposes  and  to  use  as 
scratch  space  during  execution.  The  CADDB  applications  interface  has  been  designed  to  interact  effec¬ 
tively  with  the  DMM.  For  example,  all  entities  include  descriptions  of  the  amount  of  data  which  they 
contain  so  that  the  proper  memory  block  request  can  be  made  prior  to  retrieving  the  data.  Techniques 
found  in  older  systems,  such  as  in  NASTRAN,  in  which  all  available  memopy  "s  allocated  prior  to  entering 
the  module,  should  not  be  used,  although  they  may  be  emulated  using  the  ASTROS  DMM, 

When  incorporating  other  codes  into  the  ASTROS  system,  it  is  desirable  to  conform  to  the 
ASTROS  requirement  that  all  input  come  from  the  input  data  stream  and  subsequently  be  a v 'viable  on 
the  database.  Although  user  input  to  a  module  can  come  from  the  MAPOL  sequence  or  any  external  file, 
more  typically,  input  will  come  from  bulk  data  entries  which  are  loaded  at  run  time  into  eorrenponding 
database  relational  entities.  The  use  of  external  files  should  be  minimized  because  of  the  strongl; 
machine  dependent  nature  of  the  I/O  interface  and  potential  conflicts  with  the  existing  I/O  interface 
He>  FORTRAN  READ  statements  should  not  appear  in  any  of  the  new7  modules.  Instead,  a  suitable  eev 
cf  database  entities  should  be  designed  such  that  existing  READ  statements  can  be  replaced  with  queries 
to  the  database.  As  with  the  calls  to  the  memory  manager,  described  in  Section  8.3,  a  common  practice  is 
to  group  the  database  calls  in  a  high  level  or  driver  routine  in  a  module  and  then  pass  the  retrieved  data 
to  the  lower  level  routines  through  parameter  lists.  This  helps  to  keep  the  engineering  routines  free  of  the 
otherwise  extraneous  clutter  which  can  result  from  a  series  of  memory  manager  and  database  requests. 
This  method  is  most  effective  when  installing  existing  code  as  an  ASTROS  module. 

Three  types  of  database  entities  (relational,  matrix,  and  unstructured)  are  u3ed  in  ASTROS. 
Entities  derived  from  the  bulk  data  will  typically  be  relational  or  matrix,  while  entities  which  are  written 
in  an  engineering  module  can  be  of  any  type.  Regardless  of  the  type  of  entity,  it  must  be  opened  with  the 
DBOPEN  database  utility  routine  before  any  I/O  operations  are  performed,  and,  when  no  more  I/O  will  be 
done  on  the  entity  in  the  current  module,  it  must  be  closed  with  the  DBCLOS  routine.  Each  entity  type 
has  its  own  suite  of  database  management  utilities,  and  these  are  documented  in  Section  8.  The  CADDB 
application  programming  interface  is  fairly  complex  and  consists  of  a  large  number  of  individual  utilities 
which  may  prove  daunting  to  the  novice  ASTROS  programmer  —  this  is  especially  true  of  th?  matrix 
entity  access  methods.  Section  8  is  full  of  simple  examples,  however,  which  indicate  the  range  of  capabil¬ 
ity  of  the  CADDB  interface.  The  reader  is  strongly  encouraged  to  study  Section  8  and  to  write  some 
simple  routines  to  practice  the  interface.  The  experienced  ASTROS  programmer  will  find  that  the 
CADDB  interface  greatly  simplifies  the  task  of  writing  almost  any  piece  of  ASTROS  software. 
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10.4.  CODING  PRACTICE  —  THE  ASTROS  INTERFACE 


The  architecture  of  the  ASTROS  system  lends  itself  to  enhancements.  Nevertheless,  the  addition 
of  new  code  is  not  a  trivial  task,  and  is  further  complicated  by  the  flexibility  of  the  MAPOL  language  to 
handle  optional  arguments,  functions  and  subroutines,  procedures  and  looping  instructions,  all  of  which 
play  an  important  role  in  designing  the  module  interface.  The  programmer  is  left  with  the  difficult  task  of 
deciding  how  best  to  accomplish  the  interface  in  an  environment  so  flexible  that  no  clues  are  given  at  to 
how  best  to  proceed.  All  that  can  be  suggested  is  that  existing  modules  be  used  as  examples  and  that 
experience  will  shed  light  on  the  best  methods  to  access  modules. 

Typically  addition  of  new  code  is  accomplished  by  adding  a  MAPOL  callable  module.  This  will  be 
accompanied  by  the  modification  of  several  of  the  SY3GEN  input  files  used  for  generating  the  ASTROS 
System  database.  These  files  are  U)  the  module  definition  file  (MODDEF),  (2)  the  relational  schema  file 
(RELATION),  (3)  the  module  control  sequence  (MAPOL),  (4)  the  bulk  data  template  file  (TEMPLATE), 
and  (5)  the  error  message  file  (SERRMSG).  The  capitalized,  parenthetical  words  represent  typical  root 
names  of  these  files  for  ease  of  reference.  The  format  for  each  of  these  files  is  specified  in  Section  3  2.  The 
motivation  behind  each  modification  is  described  in  the  following  notes: 

MODDEF  must  be  modified  to  define  the  new  module  to  the  system  so  that  it  may  be  called  from 
the  MAPOL  sequence.  If  the  module  perforins  a  function  that  may  be  generieally  applied  to  more 
than  one  database  entity  of  the  same  type  and  form,  it  may  then  be  desirable  to  include,  with  the 
module  definition,  calling  argument  definitions  to  pass  in  the  names  of  the  entities  to  be  used. 

RELATION  must  be  updated  to  define  the  relational  schemata  of  all  the  new  relational  database 
entities  :n  the  module,  including  those  associated  with  new  bulk  data  entries.  Relational  sche¬ 
mata  can  be  denned  instead  through  application  calls  to  CADDB  within  the  new  module:  how¬ 
ever,  this  is  cumbersome  and  may  lead  to  problems  when  the  module  is  executed  more  than  once 
or  not  at  all.  Therefore,  all  relations  should  be  defined  through  the  SYSGEN  RELATION  file  and 
all  intermodular  entities  should  be  created  by  the  executive  (through  a  MAPOL  declaration). 

MAPOL  must  be  changed  if  the  new  module  is  to  be  a  part  of  the  standard  module  control  se¬ 
quence.  Otherwise,  it  will  be  necessary  to  include  a  new  MAPOL  sequence  or  an  EDIT  of  the 
standard  sequence  in  the  input  data  file  of  every  ASTROS  job  which  will  use  the  new  module.  In 
either  case,  the  names  and  types  of  all  new  (and  old)  database  entities  which  will  be  opened  dur¬ 
ing  a  run  must  be  declared  in  the  MAPOL  sequence  which  is  used.  However,  a  programmer 
should  not  modify  the  standard  sequence  unless  he/she  is  very  familiar  with  the  ASTROS  sys¬ 
tem.  The  MAPOL  EDIT  feature  pio\  js  the  necessary  capabilities  and  avoids  possible  corrup¬ 
tion  of  the  standard  sequence. 

TFMPLATE  must  be  revised  to  define  new  bulk  data  entries  if  the  module  requires  any  input 
da«a  that  cannot  be  supplied  by  the  current  bulk  data  entries  and/or  other  engineering  modules. 
Every  template  definition  must  have  a  corresponding  entity  definition  to  which  the  data  are 

loaded. 

ERRMSO  must  be  update  d  to  include  any  new  error  message  texts  that  are  to  be  accessed 
through  the  en«r  message  output  utility;  UTMWRT,  documented  in  Section  6.  Unless  the  module 
is  to  be  made  a  permanent  part  of  the  ASTROS  system,  it  may  be  preferable  to  write  informa- 
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tional  and  error  messages  directly  to  the  output  file.  As  mentioned  in  the  following,  the  unit  num 
ber  of  the  output  file  can  be  found  in  the  /UNITS/  common  block. 

If  communication  is  desired  between  subroutines  within  the  new  module,  it  is  suggested  that 
common  blocks  be  avoided,  especially  common  blocks  containing  fixed  length  arrays  which  place  hard 
coded  limits  on  problem  size.  Use  of  common  blocks  tends  to  obscure  a  module’s  structure  and  to  reduce 
readability  and  maintainability.  Instead,  variables  and  arrays  should  be  passed  through  the  subroutines 
calling  lists.  In  cases  where  an  older  code  has  made  prolific  use  of  memory  pointers  (as  in  COSMIC/NAS- 
TRAN),  there  may  be  so  many  pointers  to  be  passed  that  it  is  more  convenient  to  place  them  within  a 
common  block  than  to  pass  them  through  argument  lists.  This  approach  can  be  justified  by  the  fact  that 
these  pointers  are  set  once  in  an  upper  level  routine  in  the  module  and  then  never  modified.  If  new 
common  blocks  are  introduced,  care  must  be  taken  to  ensure  that  unique  common  block  names  are  used. 

For  communication  between  modules,  the  database  must  be  used.  Common  blocks  must  never  be 
used  for  intermodular  communication  except  for  certain  system  level  common  blocks.  The  exception  to  the 
prohibit  ion  of  common  blocks  is  for  common  blocks  which  contain  .system  parameters,  such  as  FORTRAN 
I/O  unit  numbers,  and  mathematical  constants,  such  as  it.  These  quantities  are  so  pervasive  that  requir¬ 
ing  that  they  be  passed  through  argument  lists  could  be  unduly  burdensome.  The  following  system  level 
common  blocks  are  used  throughout  ASTROS: 


COMMON / CONDAS / 

PI,  TWOPI,  PADEG,  DEGRA 

1 

FORPI2 

COMMON / CON  AD/ 

DPI,  DTWOPI,  DRADEG,  DDEGRA, 

1 

D4PISQ 

COMMON/UNITS/ 

IUNIT  (15) 

COMMON/ OUT PT1/ 

NLPP,  MAXLIN,  PAGENO,  LINE, 

1 

TOTLIN 

COMMON / OUT  PT2 / 

TITLE,  SUBTIT,  LABEL,  HEAD1 - 

1 

HEAD2,  HEAD3 

/CONDAS/  and  /CONDAD/'  are  set  in  block  data  routine  ASTRBD  and  contain  single  and  double 
precision  versions,  respectively,  of  trigonometric  quantities.  These  are  it ,  2  n,  the  multiplier  from  radians 

to  degrees,  the  multiplier  from  degrees  to  radians,  and  4  it2,  /UNITS/,  /OUTPT1/,  and  /OUTPT2/  are  set 
and  documented  in  block  data  routine  XXBD.  /UNITS/  contains  the  FORTRAN  file  unit  numbers  for 
ASTROS  I/O.  IUNIT(1J  is  the  ASTROS  input  file  and  IUNIT(2)  is  the  ASTROS  output  file.  /OUTPT1/ 
and  /OUTPT2/  contain  quantities  used  to  control  the  formatting  of  data  output.  These  two  common  blocks 
should  be  included  in  any  utility  module  which  uses  the  UTPAGE  application  utility  module  (documented 
in  Section  6).  NLPP  represents  the  number  of  lines  per  page,  MAXLIN  is  the  maximum  number  of  output 
lines  allowed  p  *r  ASTROS  run,  PAGENO  is  the  current  page  number,  L.INE  is  the  current  line  number, 
TOTLIN  is  the  fatal  number  of  lines  output  so  far,  and  TITLE,  SUETIT,  LABEL,  HEAD1,  HEAD2,  and 
HEADd  are  the  tide,  subtitle,  lable,  and  headers  which  will  be  output  in  ‘hat  order  at  the  top  of  each 
page.  Of  these,  LINE,  UR  ADI,  HEAD2,  and  HEAD3  are  the  only  variables  that  should  be  assigned  by  a 
routine  which  utilizes  UTPAGE. 
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